Does ogre care the accuracy of semantic of the API?
-
- Gnoblar
- Posts: 12
- Joined: Thu Aug 22, 2013 7:56 am
Does ogre care the accuracy of semantic of the API?
Take some questions for example:
Ogre::RenderWindow::addViewport takes a camera as input, and a Ogre::Camera::setAspectRatio needs information about a viewport, so camera and viewport depend on each other, this is not clear.
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?
I don't know if ogre cares about these semantic problems much. If it does, I'd like to help to improve it for long.
Ogre::RenderWindow::addViewport takes a camera as input, and a Ogre::Camera::setAspectRatio needs information about a viewport, so camera and viewport depend on each other, this is not clear.
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?
I don't know if ogre cares about these semantic problems much. If it does, I'd like to help to improve it for long.
-
- Google Summer of Code Student
- Posts: 550
- Joined: Thu Jun 04, 2009 5:07 pm
- Location: Berlin
- x 108
Re: Does ogre care the accuracy of semantic of the API?
This could be something for 2.x?
Google Summer of Code 2012 Student
Topic: "Volume Rendering with LOD aimed at terrain"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Mattan Furst
Volume GFX, accepting donations.
Topic: "Volume Rendering with LOD aimed at terrain"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Mattan Furst
Volume GFX, accepting donations.
-
- Gnoblar
- Posts: 12
- Joined: Thu Aug 22, 2013 7:56 am
Re: Does ogre care the accuracy of semantic of the API?
Yes, practically it should be.PhilipLB wrote:This could be something for 2.x?
- spacegaier
- OGRE Team Member
- Posts: 4304
- Joined: Mon Feb 04, 2008 2:02 pm
- Location: Germany
- x 135
- Contact:
Re: Does ogre care the accuracy of semantic of the API?
Yes, such potential API-breaking, but at least Ogre-pattern breaking, changes would make sense in 2.0 I guess. But they of course also introduce some risks ("never change a running system ").
Do you have a complete lists of semantics issues? Perhaps a JIRA ticket with the list would be a good start to get that topic moving forward.
Do you have a complete lists of semantics issues? Perhaps a JIRA ticket with the list would be a good start to get that topic moving forward.
Ogre Admin [Admin, Dev, PR, Finance, Wiki, etc.] | BasicOgreFramework | AdvancedOgreFramework
Don't know what to do in your spare time? Help the Ogre wiki grow! Or squash a bug...
Don't know what to do in your spare time? Help the Ogre wiki grow! Or squash a bug...
-
- Gnoblar
- Posts: 12
- Joined: Thu Aug 22, 2013 7:56 am
Re: Does ogre care the accuracy of semantic of the API?
Not yet. Glad to see the needs, I'll try to post some one as a JIRA ticket to see the response.spacegaier wrote:Yes, such potential API-breaking, but at least Ogre-pattern breaking, changes would make sense in 2.0 I guess. But they of course also introduce some risks ("never change a running system ").
Do you have a complete lists of semantics issues? Perhaps a JIRA ticket with the list would be a good start to get that topic moving forward.
- Kojack
- OGRE Moderator
- Posts: 7157
- Joined: Sun Jan 25, 2004 7:35 am
- Location: Brisbane, Australia
- x 534
Re: Does ogre care the accuracy of semantic of the API?
The comments above the Camera class in ogrecamera.h say:jronald wrote: Ogre::RenderWindow::addViewport takes a camera as input, and a Ogre::Camera::setAspectRatio needs information about a viewport, so camera and viewport depend on each other, this is not clear.
The comments above the Viewport class in ogreviewport.h say:Cameras maintain their own aspect ratios, field of view, and frustum,
and project co-ordinates into a space measured from -1 to 1 in x and y,
and 0 to 1 in z. At render time, the camera will be rendering to a
Viewport which will translate these parametric co-ordinates into real screen
co-ordinates. Obviously it is advisable that the viewport has the same
aspect ratio as the camera to avoid distortion (unless you want it!).
I think that makes it fairly clear that cameras and viewports have a codependency.A viewport is the meeting of a camera and a rendering surface -
the camera renders the scene from a viewpoint, and places its
results into some subset of a rendering target, which may be the
whole surface or just a part of the surface. Each viewport has a
single camera as source and a single target as destination. A
camera only has 1 viewport, but a render target may have several.
Although the only time a camera uses a viewport is in the call to Camera::_renderScene which takes a viewport as a parameter (needed so the projection matrix can be generated). Camera::setAspectRatio doesn't use viewports.
-
- Gnoblar
- Posts: 12
- Joined: Thu Aug 22, 2013 7:56 am
Re: Does ogre care the accuracy of semantic of the API?
I should say the interdependence is not necessary.Kojack wrote:The comments above the Camera class in ogrecamera.h say:jronald wrote: Ogre::RenderWindow::addViewport takes a camera as input, and a Ogre::Camera::setAspectRatio needs information about a viewport, so camera and viewport depend on each other, this is not clear.The comments above the Viewport class in ogreviewport.h say:Cameras maintain their own aspect ratios, field of view, and frustum,
and project co-ordinates into a space measured from -1 to 1 in x and y,
and 0 to 1 in z. At render time, the camera will be rendering to a
Viewport which will translate these parametric co-ordinates into real screen
co-ordinates. Obviously it is advisable that the viewport has the same
aspect ratio as the camera to avoid distortion (unless you want it!).I think that makes it fairly clear that cameras and viewports have a codependency.A viewport is the meeting of a camera and a rendering surface -
the camera renders the scene from a viewpoint, and places its
results into some subset of a rendering target, which may be the
whole surface or just a part of the surface. Each viewport has a
single camera as source and a single target as destination. A
camera only has 1 viewport, but a render target may have several.
Although the only time a camera uses a viewport is in the call to Camera::_renderScene which takes a viewport as a parameter (needed so the projection matrix can be generated). Camera::setAspectRatio doesn't use viewports.
1. the camera is defined with parameters including a aspect ratio.
2. the viewport can be generated through the camera automatically.
- Kojack
- OGRE Moderator
- Posts: 7157
- Joined: Sun Jan 25, 2004 7:35 am
- Location: Brisbane, Australia
- x 534
Re: Does ogre care the accuracy of semantic of the API?
In this case wouldn't each camera need to keep a list of viewports? You can currently have multiple viewports sharing the same camera.jronald wrote:the viewport can be generated through the camera automatically.
Rendering also needs to be ordered by viewport z order, having multiple viewports of various z orders stored in multiple cameras seems rather messy to order correctly compared to the current system of a list of viewports that are rendered in order and each calls the single camera it knows (but the camera can be reused multiple times for different viewports because it takes the viewport as a parameter each time it's rendered).
Or go the other way and make cameras not know about viewports by passing viewport height to Camera::_renderScene instead of a viewport pointer (and change various locations in the rest of ogre like volume, terrain, shadows and compositor that ask cameras for the viewport).
(Note: I'm not against these kind of changes, I'm a big fan of the papercut forum, where api breaking small changes can be proposed that improve the api. There are other things like this that do annoy me such as how Node (which is a non renderable base class) is dependent on meshes, materials and other things so it can draw a wireframe of itself, instead of the scenemanager doing the debug rendering and leaving Node clean)
-
- Gnoblar
- Posts: 12
- Joined: Thu Aug 22, 2013 7:56 am
Re: Does ogre care the accuracy of semantic of the API?
One camera has multiple views, this doesn't sound natural. If the function is useful, use new concepts, to make things natural, also not misleading.Kojack wrote: In this case wouldn't each camera need to keep a list of viewports? You can currently have multiple viewports sharing the same camera.
It is a general problem, not about math but semantic.Kojack wrote: (Note: I'm not against these kind of changes, I'm a big fan of the papercut forum, where api breaking small changes can be proposed that improve the api. There are other things like this that do annoy me such as how Node (which is a non renderable base class) is dependent on meshes, materials and other things so it can draw a wireframe of itself, instead of the scenemanager doing the debug rendering and leaving Node clean)
- dark_sylinc
- OGRE Team Member
- Posts: 5299
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1279
- Contact:
Re: Does ogre care the accuracy of semantic of the API?
I noticed this problem too and am fixing it as we speak.jronald wrote:Ogre::RenderWindow::addViewport takes a camera as input, and a Ogre::Camera::setAspectRatio needs information about a viewport, so camera and viewport depend on each other, this is not clear.
The thing is, as said, we usually use a 1:1 camera viewport relationship, but it is possible to have one camera and multiple viewports. It is very counter intuitive, but that's the way it was handled in the 2000s the old school efects like rear mirrors for car games and reflections using scissor clipping when there was no render to texture capabilities.
Compositor scene passes will be a much more intuitive way of sharing the camera while rendering to different portions of the screen
- Kojack
- OGRE Moderator
- Posts: 7157
- Joined: Sun Jan 25, 2004 7:35 am
- Location: Brisbane, Australia
- x 534
Re: Does ogre care the accuracy of semantic of the API?
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.dark_sylinc wrote: but it is possible to have one camera and multiple viewports. It is very counter intuitive,
There's also the possibility to change material schemes per viewport, allowing very different rendering of the same camera, such as splitting the screen to show normal rendering on one side with debug rendering (like a depth encoded mipmap texture) without the need to make the code control two synchronised cameras instead of one.
So the new compositor system will allow one camera to render it's view multiple times into different regions of a single viewport without using shaders? Is calling addViewport twice really so bad in comparison?dark_sylinc wrote:Compositor scene passes will be a much more intuitive way of sharing the camera while rendering to different portions of the screen
(I don't use multiple viewports per camera so it really doesn't affect me and I have no personal interest in it, but if apis are broken or functionality is going to be lost (such as viewports sharing cameras) there should be a devil's advocate)
I never mentioned math.jronald wrote:It is a general problem, not about math but semantic.
But I also don't see where the semantic conflict is for viewports and cameras.
Is it a bad design? Maybe. Could it be done better? Probably. Is it a "semantic" error? I really don't believe so.
-
- Gnoblar
- Posts: 12
- Joined: Thu Aug 22, 2013 7:56 am
Re: Does ogre care the accuracy of semantic of the API?
By definition, does a camera only reflect what it sees?Kojack wrote: I never mentioned math.
But I also don't see where the semantic conflict is for viewports and cameras.
Is it a bad design? Maybe. Could it be done better? Probably. Is it a "semantic" error? I really don't believe so.
One world, multiple views, of course, this is very good, but should not use the concept of camera, don't change the definition of camera.
- dark_sylinc
- OGRE Team Member
- Posts: 5299
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1279
- Contact:
Re: Does ogre care the accuracy of semantic of the API?
Well, said like that doesn't sound so counter-intuitive.Kojack wrote: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.dark_sylinc wrote: but it is possible to have one camera and multiple viewports. It is very 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)
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.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?
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).
- Kojack
- OGRE Moderator
- Posts: 7157
- Joined: Sun Jan 25, 2004 7:35 am
- Location: Brisbane, Australia
- x 534
Re: Does ogre care the accuracy of semantic of the API?
Maybe I'm just overly sensitive to this because:
- I've used viewports a lot (19 viewport cylindrical panoramas, 3 viewport eyefinity 48:10 display, current oculus rift support with dual viewports). So I might be biased. Then again, I've been teaching ogre for a decade, so I'd like to think I'm not blind to the experiences of people learning ogre.
- Mixing compositors, multiple viewports and shaders has been a painful experience, it's one of the reasons why my oculus rift support is stalled (because of the way the compositor system clones input materials, modifies the clones, makes them private and hides them from the material manager, which makes it annoying to do real time changes to materials). So any mention of compositors in relation to multiple viewports makes me wary (since I don't know the plans for the 2.0 compositor system).
- One camera rendering the same scene onto multiple viewports of a larger screen is the same concept as a traditional film camera exposing the same scene onto multiple frames of a roll of film. In both cases the rendering/exposing happens one at a time (each viewport on a window gets a turn to look through the camera. Each frame on a roll of film gets a turn to be exposed through the camera).
- I've used viewports a lot (19 viewport cylindrical panoramas, 3 viewport eyefinity 48:10 display, current oculus rift support with dual viewports). So I might be biased. Then again, I've been teaching ogre for a decade, so I'd like to think I'm not blind to the experiences of people learning ogre.
- Mixing compositors, multiple viewports and shaders has been a painful experience, it's one of the reasons why my oculus rift support is stalled (because of the way the compositor system clones input materials, modifies the clones, makes them private and hides them from the material manager, which makes it annoying to do real time changes to materials). So any mention of compositors in relation to multiple viewports makes me wary (since I don't know the plans for the 2.0 compositor system).
- One camera rendering the same scene onto multiple viewports of a larger screen is the same concept as a traditional film camera exposing the same scene onto multiple frames of a roll of film. In both cases the rendering/exposing happens one at a time (each viewport on a window gets a turn to look through the camera. Each frame on a roll of film gets a turn to be exposed through the camera).
True, getViewport should probably be something like getLastViewport, because that is what it really does.dark_sylinc wrote: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).
- dark_sylinc
- OGRE Team Member
- Posts: 5299
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1279
- Contact:
Re: Does ogre care the accuracy of semantic of the API?
Kojack wrote:(I don't use multiple viewports per camera so it really doesn't affect me and I have no personal interest in it, but if apis are broken or functionality is going to be lost (such as viewports sharing cameras) there should be a devil's advocate)
I find both statements slightly contradictoryKojack wrote:Maybe I'm just overly sensitive to this because:
- I've used viewports a lot (19 viewport cylindrical panoramas, 3 viewport eyefinity 48:10 display, current oculus rift support with dual viewports). So I might be biased. Then again, I've been teaching ogre for a decade, so I'd like to think I'm not blind to the experiences of people learning ogre.
Well, whatever you have in mind; take note that you in order to move to 2.x; you'll have to port part of your code; whether that includes viewports or not. So it will take you effort whether you oppose or not
I see you have experience taking it to extremes (cylindrical panoramas!?, eyeinfinity 48:10!? occulus rift?!); which will come in handy to debug whatever bug I'll introduce.
I'll also want your input to configuring CompositorPasses so that all these techs can be supported with little effort.
Remember to PM when GSoC is over.
I share that pain. And I'm doing my best to solve it!Kojack wrote: - Mixing compositors, multiple viewports and shaders has been a painful experience, it's one of the reasons why my oculus rift support is stalled (because of the way the compositor system clones input materials, modifies the clones, makes them private and hides them from the material manager, which makes it annoying to do real time changes to materials). So any mention of compositors in relation to multiple viewports makes me wary (since I don't know the plans for the 2.0 compositor system).
Btw. another reason performance improvement from Ogre 2.0 is that Occulus is very lag sensitive. According to what I've heard, anything below 60fps feels weird and gives headache. And less than 30fps just ruins the experience.
Since Ogre 2.0 can easily achieve 60fps where 1.x achieved 20fps; well... you get the idea.
-
- Gnoblar
- Posts: 12
- Joined: Thu Aug 22, 2013 7:56 am
Re: Does ogre care the accuracy of semantic of the API?
I think compositor program, shader program and C++ program are not design as one system ahead, so the cooperation may be too technical. Practically using ogre camera for multiple views is much easier, but the functionality of ogre camera is not so natural, does using more basic concepts better than using one advanced concept here?Kojack wrote: - Mixing compositors, multiple viewports and shaders has been a painful experience, it's one of the reasons why my oculus rift support is stalled (because of the way the compositor system clones input materials, modifies the clones, makes them private and hides them from the material manager, which makes it annoying to do real time changes to materials). So any mention of compositors in relation to multiple viewports makes me wary (since I don't know the plans for the 2.0 compositor system).
- One camera rendering the same scene onto multiple viewports of a larger screen is the same concept as a traditional film camera exposing the same scene onto multiple frames of a roll of film. In both cases the rendering/exposing happens one at a time (each viewport on a window gets a turn to look through the camera. Each frame on a roll of film gets a turn to be exposed through the camera).
- Kojack
- OGRE Moderator
- Posts: 7157
- Joined: Sun Jan 25, 2004 7:35 am
- Location: Brisbane, Australia
- x 534
Re: Does ogre care the accuracy of semantic of the API?
Not really.dark_sylinc wrote: I find both statements slightly contradictory
"I've used viewports a lot"
True. Well, not all the time, but probably more than average.
"I don't use multiple viewports per camera so it really doesn't affect me and I have no personal interest in it"
True. Note that I said "multiple viewports PER camera". When I do things like 19 viewports, I have 19 cameras aimed in different directions. With that many viewports you can get nice looking pseudo curved cylindrical projection without shaders (at the cost of ogre's scene traversal running 19 times, which is a bit hit)
Torchlight 2 runs rather nicely at 5040x1050 (48:10).dark_sylinc wrote: eyeinfinity 48:10!?
http://imageshack.us/a/img19/125/09222012063123731.jpg
(Although that used one viewport and camera, while mine use three of each to get a wrap around projection rather than stretched)