Kojack wrote:dark_sylinc wrote: but it is possible to have one camera and multiple viewports. It is very counter intuitive,
Is one source going to two different outputs really that counter intuitive? Think of using two monitors in duplicate mode (such as I use every day at work to have a projector show the same thing as my pc). That's not viewports and cameras or even 3d rendering, but the same concept: one source of image goes to two different (and even different sized) targets.
Well, said like that doesn't sound so counter-intuitive.
However when we look at the code, it's confusing. We have viewport->getCamera and camera->getViewport.
While viewport->getCamera works as expected, camera->getViewport reports the last viewport that was associated with (which can change after each renderOneFrame or renderTarget->update call).
The co-dependence makes really hard to think of Viewports as the concept you describe (which really was the idea: two regions in memory using the same camera can have different material schemes, visibility flags, etc). What is the difference between a Viewport & a Camera is a bit blurry. Plus the choice of words makes it harder to guess.
Compositor Scene passes will be easier to understand because they act very much like viewports (they can share cameras, draw to different regions of the same texture, draw to different textures, use different material schemes, etc) but Camera has no idea which Compositor Scene Pass is currently using them (better isolation).
Plus, compositor scene passes are "passes where you draw the scene into some place"; which makes, through the wording, easier to guess.
Furthermore passes are easier to setup in Compositor scripts, while Viewports aren't. Ogre 1.x users have to deal directly with RenderTargets & Viewports to setup multiple viewports sharing the same camera.
In other words... to clarify, I'm not removing Viewport functionality, just designing it for easier use (aka "correctness" which was the main point of the post)
jronald wrote:Ogre::Root::setRenderSystem should call before Ogre::Root::initialise, the semantic is not natural, why not let Ogre::Root::initialise take a parameter of Ogre::RenderSystem?
Sinbad knows better, Root is probably the oldest interface in Ogre. As such, stuff like design choices, mistakes, having to readapt to different architectures, dragged along.
I agree there are some ugly stuff about Root. For starters, half of the pointers aren't initialized in the constructor, but they're deleted in the destructor; just to name one issue that bugs me.
But Root works, and it's barely touched (I guess it hasn't been refactored because it's big, it can easily & randomly break application launches if you screw up an uninitialized variable, and it's something that you setup once and then forget about it).