[REQ] navigation improvements in OpenGL preview
- zeitmeister
- Posts: 2010
- Joined: Tue Apr 22, 2008 4:11 am
- Location: Limburg/Lahn, Germany
- Contact:
[REQ] navigation improvements in OpenGL preview
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!
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!
Cheers, David
DAVIDGUDELIUS // 3D.PORTFOLIO
·
Indigo 4.4.15 | Indigo for C4D 4.4.13.1 | C4D R23 | Mac OS X 10.13.6 | Windows 10 Professional x64
DAVIDGUDELIUS // 3D.PORTFOLIO
·
Indigo 4.4.15 | Indigo for C4D 4.4.13.1 | C4D R23 | Mac OS X 10.13.6 | Windows 10 Professional x64
Re: [REQ] navigation improvements in OpenGL preview
+1
Adding to that idea, (I know you guys are busy lol) perhaps a navigation sensitivity slider?
Adding to that idea, (I know you guys are busy lol) perhaps a navigation sensitivity slider?
Re: [REQ] navigation improvements in OpenGL preview
There is one already, check the options dialog.
- zeitmeister
- Posts: 2010
- Joined: Tue Apr 22, 2008 4:11 am
- Location: Limburg/Lahn, Germany
- Contact:
Re: [REQ] navigation improvements in OpenGL preview
Oh cool, thank you!
Cheers, David
DAVIDGUDELIUS // 3D.PORTFOLIO
·
Indigo 4.4.15 | Indigo for C4D 4.4.13.1 | C4D R23 | Mac OS X 10.13.6 | Windows 10 Professional x64
DAVIDGUDELIUS // 3D.PORTFOLIO
·
Indigo 4.4.15 | Indigo for C4D 4.4.13.1 | C4D R23 | Mac OS X 10.13.6 | Windows 10 Professional x64
Re: [REQ] navigation improvements in OpenGL preview
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
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
- Posts: 1459
- Joined: Tue Apr 08, 2008 9:37 am
- Location: Karlsruhe, BW, Germany
- Contact:
Re: [REQ] navigation improvements in OpenGL preview
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.
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.
Re: [REQ] navigation improvements in OpenGL preview
PureSpider wrote:What about making the OGL preview actually a preview while you're at it?
Is that so... just a spot of GLSL here and there and it's all done?PureSpider wrote:All this stuff can fairly easily be realized with GLSL.
- PureSpider
- Posts: 1459
- Joined: Tue Apr 08, 2008 9:37 am
- Location: Karlsruhe, BW, Germany
- Contact:
Re: [REQ] navigation improvements in OpenGL preview
http://fabiensanglard.net/bumpMapping/index.phplycium wrote:Is that so... just a spot of GLSL here and there and it's all done?
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.
Re: [REQ] navigation improvements in OpenGL preview
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.
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
- Posts: 1459
- Joined: Tue Apr 08, 2008 9:37 am
- Location: Karlsruhe, BW, Germany
- Contact:
Re: [REQ] navigation improvements in OpenGL preview
Then don't - but don't do it half-assed so that just something has been done.lycium wrote:there's also the small matter that we're not primarily writing an OpenGL rendering engine...
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).
Re: [REQ] navigation improvements in OpenGL preview
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.
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.
obsolete asset
Re: [REQ] navigation improvements in OpenGL preview
Hi CTZn,CTZn wrote: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.
The movement speed already is proportional to the scene scale.
Re: [REQ] navigation improvements in OpenGL preview
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.
Again, a planet is a big scene but possibly not the subject of the shot.
obsolete asset
Re: [REQ] navigation improvements in OpenGL preview
Ok. Could work, but sounds a little complicated.
Re: [REQ] navigation improvements in OpenGL preview
CTZn wrote: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
Who is online
Users browsing this forum: No registered users and 40 guests