[REQ] navigation improvements in OpenGL preview

[zeitmeister]

Hi,
it would be nice to have the possibility navigating slower in the OpenGL preview window; perhaps by holding SHIFT or whatever... half or third the speed.
Just a suggestion!

[ENSLAVER]

+1

Adding to that idea, (I know you guys are busy lol) perhaps a navigation sensitivity slider?

[OnoSendai]

There is one already, check the options dialog.

[zeitmeister]

Oh cool, thank you!

[lycium]

Easy peasy, done for next release I've made it about a 1/3 slower, figuring that 1/2 might be a bit too little; should it be an option?

Edit: 1/3 seems fine, and while I was in there I also made it so that if you're realime'ing around and accidentally scroll the mousewheel (when panning) it doesn't change the viewport zoom - this was driving me nuts for too long

[PureSpider]

What about making the OGL preview actually a preview while you're at it?
At the moment it flickers around like crazy when activating/minimizing/restoring/etc. the Indigo window, blends are just purple colored, transparent stuff doesn't have reflection/refraction (which is certainly possible given you need some OpenCL/Cuda levels to use Indigo at full anyway), no bump or normal maps, etc etc...
All this stuff can fairly easily be realized with GLSL.

[lycium]

What about making the OGL preview actually a preview while you're at it?

All this stuff can fairly easily be realized with GLSL.

Is that so... just a spot of GLSL here and there and it's all done?

[PureSpider]

Is that so... just a spot of GLSL here and there and it's all done?

http://fabiensanglard.net/bumpMapping/index.php
http://www.ozone3d.net/tutorials/bump_mapping.php
So bump mapping and normal mapping are really just "drop in some glsl", yeah.

Is the blend thing and the flicker really that hard to fix?

And is it, for some guys writing a high performance professional renderer, really that hard to write up some glsl code to calculate real time cube maps for reflection and refraction?
http://www.riemers.net/eng/Tutorials/XN ... hnique.php

Or code for some real time shadows?
http://www.cosc.canterbury.ac.nz/resear ... s_0705.pdf

If you want to get super-fancy, even realtime DoF is possible, rendermonkey has an example included for that.
Have a look at http://www.minecraftforum.net/topic/940 ... dows-more/
I know it's a minecraft thing but they got real time shadows and real time DoF working, so why not learn from them?

Edit: http://encelo.netsons.org/tag/glsl/ has some interesting stuff.

[lycium]

Alex I've been doing graphics programming my whole life, I know this stuff and have read many many books and tutorials. It simply isn't as easy as writing a few lines of GLSL, there are render passes and buffers and corner cases to consider. Writing good maintainable code isn't a quick thing, there's also the small matter that we're not primarily writing an OpenGL rendering engine...

There surely are improvements that can be made to the GL view (the flickering in particular) but please trust that it's not just a 30 minute GLSL job, else it would probably be done... no need to be snarky.

[PureSpider]

there's also the small matter that we're not primarily writing an OpenGL rendering engine...

Then don't - but don't do it half-assed so that just something has been done.
In my opinion, the OGL preview can't live up to Indigo's general quality AT ALL.

And I know stuff like dropping in normal or bump mapping or fixing blends so they are evaluated properly probably only takes 30 mins, if not less (not talking about the more complicated stuff here).

[CTZn]

Back on the navigation speed matter.

If one has set a terran atmosphere simulation up but want only to render a small location (house, or anything of a human scale), the problem persists. 1/2 or 1/3 differential will not make the smallest difference in making the navigation comfortable (if practicable). I'm talking about a planetary scale, an extreme example among others but my final point is to have a scalable system available.

Framing a selection (from the lister) would be the best option for me. All 3D apps do this. The camera steps would be based on the selected geometric node(s) bounding box(es) as per normal. A slider could then be added to change the order of magnitude of the navigation comfort zone.

Or use the camera frustum + focus distance (or focused surface ?) to approximate the desired navigation range. But being able to move instantly to a distant subject is a must IMHO.

(Shift-)select, frame, set.

[OnoSendai]

Back on the navigation speed matter.

If one has set a terran atmosphere simulation up but want only to render a small location (house, or anything of a human scale), the problem persists. 1/2 or 1/3 differential will not make the smallest difference in making the navigation comfortable (if practicable). I'm talking about a planetary scale, an extreme example among others but my final point is to have a scalable system available.

Framing a selection (from the lister) would be the best option for me. All 3D apps do this. The camera steps would be based on the selected geometric node(s) bounding box(es) as per normal. A slider could then be added to change the order of magnitude of the navigation comfort zone.

Or use the camera frustum + focus distance (or focused surface ?) to approximate the desired navigation range. But being able to move instantly to a distant subject is a must IMHO.

(Shift-)select, frame, set.

Hi CTZn,
The movement speed already is proportional to the scene scale.

[CTZn]

I know that and by the way it is not question to change that mechanism, only to have it dynamically target an arbitrary bb instead of always the scene's bb.

Again, a planet is a big scene but possibly not the subject of the shot.

[OnoSendai]

Ok. Could work, but sounds a little complicated.

[ENSLAVER]

I know that and by the way it is not question to change that mechanism, only to have it dynamically target an arbitrary bb instead of always the scene's bb.

Again, a planet is a big scene but possibly not the subject of the shot.

The "Frame Selection/Object" option that uses the objects bounding box to set the scale of the camera movement as CTZn suggested is probably the most elegant solution in the long run. Plus it would be awesomely useful if you are rendering separate views of different objects in the same scene, even for setting up specific materials/lighting for those objects.


Yeah, it did get complicated from a simple hotkey lol