Does ogre care the accuracy of semantic of the API?

Discussion area about developing or extending OGRE, adding plugins for it or building applications on it. No newbie questions please, use the Help forum for that.
Post Reply
jronald
Gnoblar
Posts: 12
Joined: Thu Aug 22, 2013 7:56 am

Does ogre care the accuracy of semantic of the API?

Post by jronald » Fri Aug 30, 2013 11:14 am

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.
0 x

PhilipLB
Google Summer of Code Student
Google Summer of Code Student
Posts: 550
Joined: Thu Jun 04, 2009 5:07 pm
Location: Berlin

Re: Does ogre care the accuracy of semantic of the API?

Post by PhilipLB » Fri Aug 30, 2013 11:18 am

This could be something for 2.x? :)
0 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.

jronald
Gnoblar
Posts: 12
Joined: Thu Aug 22, 2013 7:56 am

Re: Does ogre care the accuracy of semantic of the API?

Post by jronald » Fri Aug 30, 2013 12:00 pm

PhilipLB wrote:This could be something for 2.x? :)
Yes, practically it should be.
0 x

User avatar
spacegaier
OGRE Team Member
OGRE Team Member
Posts: 4291
Joined: Mon Feb 04, 2008 2:02 pm
Location: Germany
x 2
Contact:

Re: Does ogre care the accuracy of semantic of the API?

Post by spacegaier » Fri Aug 30, 2013 12:22 pm

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.
0 x
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...

jronald
Gnoblar
Posts: 12
Joined: Thu Aug 22, 2013 7:56 am

Re: Does ogre care the accuracy of semantic of the API?

Post by jronald » Fri Aug 30, 2013 1:09 pm

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.
Not yet. Glad to see the needs, I'll try to post some one as a JIRA ticket to see the response.
0 x

User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7147
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 16

Re: Does ogre care the accuracy of semantic of the API?

Post by Kojack » Fri Aug 30, 2013 1:56 pm

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 Camera class in ogrecamera.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!).
The comments above the Viewport class in ogreviewport.h say:
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.
I think that makes it fairly clear that cameras and viewports have a codependency.

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.
0 x

jronald
Gnoblar
Posts: 12
Joined: Thu Aug 22, 2013 7:56 am

Re: Does ogre care the accuracy of semantic of the API?

Post by jronald » Fri Aug 30, 2013 3:36 pm

Kojack wrote:
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 Camera class in ogrecamera.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!).
The comments above the Viewport class in ogreviewport.h say:
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.
I think that makes it fairly clear that cameras and viewports have a codependency.

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.
I should say the interdependence is not necessary.
1. the camera is defined with parameters including a aspect ratio.
2. the viewport can be generated through the camera automatically.
0 x

User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7147
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 16

Re: Does ogre care the accuracy of semantic of the API?

Post by Kojack » Sat Aug 31, 2013 8:16 am

jronald wrote:the viewport can be generated through the camera automatically.
In this case wouldn't each camera need to keep a list of viewports? You can currently have multiple viewports sharing the same camera.
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)
0 x

jronald
Gnoblar
Posts: 12
Joined: Thu Aug 22, 2013 7:56 am

Re: Does ogre care the accuracy of semantic of the API?

Post by jronald » Sat Aug 31, 2013 9:02 am

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.
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: (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)
It is a general problem, not about math but semantic.
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4040
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 216
Contact:

Re: Does ogre care the accuracy of semantic of the API?

Post by dark_sylinc » Sat Aug 31, 2013 9:13 am

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.
I noticed this problem too and am fixing it as we speak.

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
0 x

User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7147
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 16

Re: Does ogre care the accuracy of semantic of the API?

Post by Kojack » Sat Aug 31, 2013 10:15 am

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.

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.
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
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?

(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)
jronald wrote:It is a general problem, not about math but semantic.
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.
0 x

jronald
Gnoblar
Posts: 12
Joined: Thu Aug 22, 2013 7:56 am

Re: Does ogre care the accuracy of semantic of the API?

Post by jronald » Sat Aug 31, 2013 12:01 pm

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.
By definition, does a camera only reflect what it sees?
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.
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4040
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 216
Contact:

Re: Does ogre care the accuracy of semantic of the API?

Post by dark_sylinc » Sat Aug 31, 2013 10:20 pm

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).
0 x

User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7147
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 16

Re: Does ogre care the accuracy of semantic of the API?

Post by Kojack » Sun Sep 01, 2013 5:30 am

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).
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).
True, getViewport should probably be something like getLastViewport, because that is what it really does.
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4040
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 216
Contact:

Re: Does ogre care the accuracy of semantic of the API?

Post by dark_sylinc » Sun Sep 01, 2013 6:55 am

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)
Kojack 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.
I find both statements slightly contradictory :lol:

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 :D
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.
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).
I share that pain. And I'm doing my best to solve it!
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.
0 x

jronald
Gnoblar
Posts: 12
Joined: Thu Aug 22, 2013 7:56 am

Re: Does ogre care the accuracy of semantic of the API?

Post by jronald » Sun Sep 01, 2013 7:04 am

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).
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?
0 x

User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7147
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 16

Re: Does ogre care the accuracy of semantic of the API?

Post by Kojack » Sun Sep 01, 2013 12:50 pm

dark_sylinc wrote: I find both statements slightly contradictory :lol:
Not really.

"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)

:)
dark_sylinc wrote: eyeinfinity 48:10!?
Torchlight 2 runs rather nicely at 5040x1050 (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)
0 x

Post Reply