Add support for specifying shadowing far distance in Renderer settings.

[juj]

Currently (at least when using High settings for shadowing) the far end shadow distance is set very near, causing almost all shadows to fade almost immediately.

Add an option to the renderer settings dialog to specify the shadowing far distance.

[jonnenauha]

@cadaver Just for your info we are thinking of making a EC for embedding shadow configuration into the scene. As I understood it this would be a singleton type component that would define the far distance and calculate the split points with it when changed. These would also be applied to the Ogre shader parameters so the shader does the right thing.

We were first thinking of making this a Meshmoon component but we are going to have to modify OgreWorld::SetupShadows and the shader code for this, so we might as well make it open source. Probably best to put the EC to OgreRenderingModule?

EC_OgreShadowSetup sounds about right? :)

Imo the shadow setup is a scene spesific thing. If you know you have a smallish indoor scene, 50 is fine. If you do a big outdoor scene then you make it much bigger.

[Stinkfist0]

Even nicer would be to have OgreWorld and PhysicsWorld and their properties also serialized into the element in the txml. This would of course require some more work and design. I discussed the shadow biz with Lasse on IRC a bit some time ago and ideally shadow settings could be even per object setting, but that's not possible (or at least very difficult/hackish to implement, can't remember which) with current Ogre.

[Stinkfist0]

Example (also threw in scene up, fwd and right vector conf for fun which could be nice):

<scene up="0 1 0" forward="0 0 -1" right="1 0 0">
 <graphics>
  <property name="Shadow far clip distance" value="500">
 </graphics>
 <physics>
  <property name="Gravity" value="0 9.81 0">
 </physics>
<entity id="1">
 <!-- ... -->
</scene>

[jonnenauha]

That looks like a cool idea. Except when the .txml is loaded on the server. Now we need a network message to send these to all connected clients and all future ones. This mechanism is automatic in making a EC_BulletWorld and EC_OgreWorld. I'd hate to see new protocol messages for this stuff as the message stack is so clean now :)

What if we would serialize all the subsystems and make a new network message for them

<scene>
  <subsystems>
    // OgreWorld writes this block
    <rendering>
      ...
    </rendering>
    // PhysicsWorld writes this block
    <physics>
      ...
    </physics>
  </subsystems>
</scene>

and to go with it some kind of generic Subsystem network message, that would just contain this same data (not as text or xml though) that would be sent to the clients from the server.

Of course now we have the problem of how to configure these values :) We need a UI on the client side to send entity actions to a server side script that would manipulate the *World objects to have new settings, so they get serialized to txml correctly (which is saved on the server).

Comparing to the EC_ approach this would be a non issue. Surely we could apply same security policy (can you manipulate the scene) to the World objects. And if a user that has permissions modified the *World we could automatically send these things to the server just like attribute changes. But if this would be the case, it seems pointless to implement another system on the side when EC already does all of this :)

TL;DR In conclusion I dont see the point of doing another set of network messages that would do exactly the same thing as attributechanged message. When we can just have a free standing Entity with the components in the actualy scene. Auto sync to clients, client with permissions can modify the settings and it gets serialized to txml automatically.

[Stinkfist0]

Yeah, would require designing new messages and more work. But extending TXML would be nice and maybe inevitable in the long run. Also, IIRC, there were also some plans at least back in the day to be able to define set of C++ Tundra plug-ins in the TXML. Continuing with your idea, maybe this would be even nicer:

<subsystem name="GraphicsWorld">
 <property name="Shadow far clip distance" value="500">
</subsystem>
<subsystem name="PhysicsWorld">
 <property name="Gravity" value="0 9.81 0">
</subsystem>

EC_GraphicsWorld (we probably want to de-empasize Ogre and keep it more generic and suitable for non-Ogre Tundra implementations) and EC_PhysicsWorld sound pretty good. Wonder if would like to implement some kind of static const bool IComponent::singleton property to help with the "one per scene" type of ECs (Sky, Fog, etc. we have couple of them already).

[antont]

I'm with Jonne here - let's use the generic mechanism we have which exactly makes it unnecessary to invent new messages for these things. As the long-term solution.

Why not consider these worlds as entities .. or components in an entity -- that is all application data and exactly what the system is for. Jukka proposed way back then the Environment entity as a naming convention for configuring global things.

Nice XML / JSON syntax for specifying things is a different matter.

[Stinkfist0]

Actually f.ex. in Urho3D PhysicsWorld is a Component/Subsystem of the root scene Node, IIRC, and I like that. Can't remember if its properties are replicated automatically though using the generic sync mechanism. But our EC system is not exactly the same so would require a bit different design in Tundra. Wonder if it would make sense to convert OgreWorld and PhysicsWorld into proper EC_GraphicsWorld and EC_PhysicsWorld.

[jonnenauha]

static const bool IComponent::singleton this would be absolutely lovely. We have lots of these to be honest and we have problems of doing these checks in the component implementation (look at EC_SkyX source code). EC_Sky, EC_SkyX, EC_Fog, EC_MeshmoonSky, EC_MeshmoonWater, EC_Water, EC_HydraX are the ones we have not (at least) that would benefit in this kind of singleton thing. I guess if IComponent::IsSingleton() it would not be created by Scene if one of them can already be found from the scene. Though this kind of breaks CreateComponent that currently is afaik guaranteed to return a valid component (if its a known component).

On the other point. I wonder if we could make some kind of "special entities" a thing. Like PhysicsWorldEntity would be a similar singleton entity you can only have one in the scene. Or perhaps a more generic SubSystemEntity. This way we would not have to have hack solutions like naming conventions scene.EntityByName("PhysicsWorld");. Wonder if Entity could have some kind of typeName property like components. By default it would not be written but for these special ones it would.

<entity id=10 .... typeName="PhysicsWorld">

Dunno, maybe this would break our very clean and nice architecture and make it unnessarily more complex. We have been happy in meshmoon doing "RocketEnvironment" that our build mode manipulates. But at the end of the day I really dont like to rely solely on these type of naming conventions.

Just throwing ideas... Either way I'd like to not put more messages to the core protocol for subsystems. Embedding then into "special" entities and components would fit better into the Tundra system. We are already maintaining a few different clients, every protocol level change is a headache for those implementations and for Meshmoon as we have to think about users that dont update their clients every time there is a update available etc.

[Stinkfist0]

Thowing ideas is always good. Anyways, I would be totally happy for now f.ex. with the EC_GraphicsWorld + EC_PhysicsWorld (both simple data ECs like EC_Name) + "singleton" const property for IComponents.

[cadaver]

It sounds OK enough to have components for the scene settings. Eg. EC_GraphicsWorld & EC_PhysicsWorld. It would be ideal to not require these in any specifically named entity.

For the sake of stability we're probably not going to actually have these components create the Bullet & Ogre scenes, because they need to exist first. Rather the actual OgreWorld & PhysicsWorld classes will look up these components and apply the settings.

In Urho the components are the actual octree / physics world representations, which is safe because they must exist in the scene root, and both scene load and network replication are guaranteed to happen in parent->child order.

[jonnenauha]

Yeah, those would be just settings components that will be registered by the physics/renderer implementation. They can listen to them being created and for attribute changes. Or the actual component impl would react to the changes with ParentScene()->SubSystem<PhysicsWorld>()->SetGravity(gravity.Get());

Imo the component could really just be named EC_OgreWorldSettings. What attributes this component has is probably rendering/physics implementation spesific. If you dont load the Ogre module then this component is not recognized. Though then we might end up with a silly thing where server would have Ogre renderer and clients Urho renderer :) (if we ever get there). But it can be a generic EC if we can decide on a good set of attributes that any renderer/physics might need. We could then put these components (to be registered from) to Framework or Scene (like EC_Name).

Edit: Esp for these components the singleton enforcement in Scene might be useful. I think implementing this is not hard, but we need to see our C++ code that nothing crashes on null ptrs when the enforcement happens and CreateComponent() return null ptr. In scripts this is not a huge problem.

[Stinkfist0]

Yeah, simple data ECs is good. "Shadow far distance" and "gravity" are at least universal terms and cannot think of any Bullet- or Ogre-specific stuff, right now at least, requiring "OgreWorld" and "BulletWorld" type names. If/when we have f.ex. per object or per light shadow settings, those can override the global one.

BTW Could make a new issue for the "singleton EC" stuff.

[antont]

note about the 'Environment' entity idea: I was recalling that Jukka also didn't propose that any special name would be required, he just proposed it as a soft not enforced convention.

finally found that post, 'The Environment Entity' from 2010 :) https://groups.google.com/forum/#!msg/realxtend-dev/2QVTJbXAtAw/l7fGSEcQK0AJ

apparently I was recalling a bit wrong and this had more to do with the EnvironmentModule etc. from those days, was interesting enough anyhow to check original ideas from back then.

(BTW I'm not sure if like that as a convention or not - sometimes I've created an Env entity where have collected those components and sometimes made separate to configure different things)