scrawl wrote:You forgot to add the documentation to the second variant of createSceneManager (SceneTypeMask).
Ooops. Damn overloads.
scrawl wrote:Doesn't really answer my question. I'll try to word it more clearly:
- Why are these parameters duplicated (both in ShadowTextureDefinition and the various ShadowCameraSetup classes)? eg LiSPSMShadowCameraSetup::getCameraLightDirectionThreshold vs ShadowTextureDefinition::lightDirThreshold
Aahh, I see what you mean. Yeah I noticed that too*
The thing is we use the "Definition" pattern (I don't remember the real name). You're looking at the definition parameters. The ShadowCameraSetups don't get created until the Compositor nodes are instantiated; but we still to know what paremeters they will have.
Because the shadow camera setups were developed long ago, they end up duplicating those variables. If you look at the more recent classes, the definitions are actually being used i.e. CompositorPassScene accesses definition parameters from CompositorPassSceneDef through the member mDefinition.
Besides sharing, the most important reason is actually knowing those values beforehand (i.e. when parsing the compositor scripts)
*I'm referring to me as if I haven't written the code because sometimes, I feel like it's my subconscious typing
scrawl wrote:
- Why do I need to "share" camera setups? Why would 2 shadow nodes have the exact same setup? Is this for some fancy shadow technique I'm not aware of?
Ok you're mixing stuff. I see where the confusion happens.
Camera setups will be shared across the
same shadow node, but never across different shadow nodes. They're out of scope.
They are shared just to save a few bytes in ram (there was another reason but I can't remember now, anyway this is trivial). A couple revisions earlier they didn't even share the setups.
Then there is Shadow Node sharing; which is something completely different. If you have two render_scene passes, and you want to reuse the data from the older pass, you use the same shadow node.
You can also override its contents, in case you won't be using them again (the more shadow nodes you have, the more VRAM you'll need).
But if you want to have each render_scene pass each with its own shadow setups, you'll need two different shadow nodes; which may or may not contain the same settings; but they won't share their camera setups even if they contain the same settings.
A reason to have two shadow nodes with the same parameters is not crazy though: Suppose we have passes A which renders opaque geometry, B which renders environment mapped data, and C which composites A & B and renders the transparent objects.
A & B need shadows, but are independent of each other.
And C is a composite that depends on both A & B but also wants to use the shadow node's data from A.
You'll 2 shadow nodes: one for A & C, and another for B. You can just use one shadow node; but if you do so, the contents will be forced to be recalculated when doing C (because they were overwritten).
Hm, maybe pull the clear colour from somewhere else. A separate function to set it wouldn't hurt in any case. I noticed that Viewport's background color has been removed.
Yes, a couple of utility functions are needed. As more feedback is retrieved, it will be easier to see how this should be done.
The thing is it works for "very basic setups"; but for more complex setups there is hardly a notion of a unique background color. Assuming all RTs have the same background color is a very dangerous assumption.
Transporter wrote:
Why not initializing it by Ogre itself like LogManager etc.? Also it would be nice to have an option to set up the CompositorManager2 with a default workspace for a normal output.
Initially it was done that way automatically, but it was a PITA because at some point the system depended on the RenderSystem, and D3D9 was complaining that the context wasn't yet created (a RenderWindow hasn't been created).
Then I moved into Root::initialise but it failed to work if creating manual RenderWindows (autoCreateWindow = false). In the end it was just easier to manually call it after the user knows when the first RenderWindow had been created.
If you see an easier way to solve this, I'm all ears. Take in mind it looks troublesome now, but once you've written the initialization routine you won't be worrying about it again.
Where are the functions setPosition and setDirection for lights without a scene node? I can't find them.
Ohh, looks like the Doxygen doc needs an update. All MovableObjects need a SceneNode now (it's in section ... oh wait I may have forgotten to document it! Sorry
; I'm sure I wrote it somewhere).
Creating a camera will automatically create a SceneNode for you since this is the most common behavior (having SceneNode-less cameras). But for lights, it was 50/50 so it was a hard choice.
Light::setPosition is missing, which should redirect to the SceneNode. This was a bit intentional so I could spot which Lights used nodes when porting.
Are you shure that the frame statistics are correct?
As you can see, I have between 4898 and 10593 fps. This should be an avarage frame rate of 0.4?
Ooops, the average frame rate is in milliseconds. 1000 / 0.4 = 2500 fps.
Maybe you could add an example how to setup an OGRE2 application to your porting Manual.
Good idea.