PDA

View Full Version : Enhancing the Preview feature to evolve to GPU rendering



vncnt
11-16-2019, 05:28 AM
In LW 2019 the "Show OpenGL UI" feature has been introduced.
For me, this upgraded the Preview feature in the direction of GPU rendering.

Personally I don't expect GPU rendering to be (fully) implemented in a next version of Lightwave
but it is intriguing to come up with small improvements that allow the system to
evolve step by step towards CPU rendering.

So I wonder, what steps would that be and what steps could be
preferably implemented without making it too difficult for developers or
interfere with an existing development path.

My suggestion would be to add a Preview Option to render to the current Camera resolution because
many clients (or their clients) find it difficult to judge very basic preview clips that have
technical issues like crop/resizing/resolution. Selling a preview shot is selling my project.
Just submitted this suggestion (and motivation) as a feature request.

What would enhance the Preview system for you, and why?

erikals
11-16-2019, 04:05 PM
cpu+gpu is the way to go.

https://i.imgur.com/XrvJZXi.png

prometheus
11-16-2019, 09:25 PM
There are some undocking and use camera resolution for the display preferences, but it doesnīt seem to result in exact camera resolution, I actually thought it did, but revisiting in both 2019 and 2015, I do not see that is accurate to use for exact camera resolution..weird.

Also, for the preview system (VPR) I am frustrated by two things, I can not save the preview image in one go with the same name as the scene, I would like to have a default use scenename check box option for vpr saved images, and the other frustration is not being able to pause VPR and continue to refine when I need, especially when something is needed to find something else on the net or just need a brake, Blenders preview system has this for the interactive renderer in cycles, on the other hand, as far as I am aware of, you can not preview render it, unless just changing your render settings to preview and start the renderer.

Ma3rk
11-16-2019, 09:51 PM
cpu+gpu is the way to go.

https://i.imgur.com/XrvJZXi.png

Nah, nah. You need some REAL Power ...

146283

https://www.youtube.com/watch?v=F4QzrKakPmU

Rayek
11-17-2019, 01:46 PM
on the other hand, as far as I am aware of, you can not preview render it, unless just changing your render settings to preview and start the renderer.

A workaround is to create a full linked scene copy, and set up preview render settings for that scene. When you switch to that "preview" scene hitting the F12 key renders a preview. It is also possible to set up a new Main Window (Window-->New Main Window), and switch that view to the "preview scene". On a multiple screen setup just click the "preview" main window, and hit F12 to render a preview.

It is also possible to change the pixel size of the interactive viewport preview in the Performance/Viewport settings.

As far as I am aware, there is no way to save Cycles' generated interactive views directly as an image. I use Greenshot to solve this, and which gives me more options what to do with the screenshot (save it, directly save it, send to my image editor, copy, etc.).

Dan Ritchie
11-17-2019, 03:33 PM
cpu+gpu is the way to go.

https://i.imgur.com/XrvJZXi.png

I did some experimenting with load balancing between CPU and GPU a number of years ago, and the benefit of running the same code on both at the same time was negligible.
I also have concerns that utilizing only the compute part of the GPU for rendering will have minimal gains over CPU only rendering. If you look at Blender, what kind of speed improvement do you get on the GPU, maybe 3x?
With faster CPUs coming along, that benefit may dwindle.

I suspect with raytracing hardware coming down the pike, a fully DirectX/OpenGL/Vulcan type of renderer would be better, since it takes advantage of the whole GPU, shaders, transforms, lighting, raytracing, compute, and so on. My 2 cents.

erikals
11-17-2019, 03:38 PM
well, if you use 2 gpus, or iow, cpu+gpu+gpu the effect/pricecut is substantial, regardless if you already have a fast cpu.

raytracing hardware is interesting, and might be something, down the line.

prometheus
11-17-2019, 03:47 PM
A workaround is to create a full linked scene copy, and set up preview render settings for that scene. When you switch to that "preview" scene hitting the F12 key renders a preview. It is also possible to set up a new Main Window (Window-->New Main Window), and switch that view to the "preview scene". On a multiple screen setup just click the "preview" main window, and hit F12 to render a preview.

It is also possible to change the pixel size of the interactive viewport preview in the Performance/Viewport settings.

As far as I am aware, there is no way to save Cycles' generated interactive views directly as an image. I use Greenshot to solve this, and which gives me more options what to do with the screenshot (save it, directly save it, send to my image editor, copy, etc.).

But that is not at All the same as making a preview renderer in Lightwave, which does so with the help of the VPR, not a lower aliasing and resolutions preview.
The workaround is a bit tedious to setup,if you compare with lightwaveīs basic make preview, whatever scene range you got, it will render and it provides you with the timeline to play it directly when it is finished, where in blender you have to start the animation renders with play rendered animation ctrl f11, itīs not that big of a deal perhaps..but it feels smoother in lightwave when making previews, though it does so with internal memory and videoformats.

On the other hand, final animation renders, and using play rendered animation directly from blender..that is something Lightwave doesnīt do as I am aware of, so you do not have to compile the frames in order to see the animation, so a kind of playblast animation function is something I really think Lightwave miss, as it is now..I need fusion or resolve to play the animation and load it there, so a simple playblast tools directly acessable from Lightwave would be nice, itīs much smoother that way in blender.

Rayek
11-17-2019, 04:34 PM
Apples and oranges... Each app does it different. If you need a quick render preview Eevee might be helpful as well. Creating a preview in Eevee will be far faster (in particular for animation) than VPR and at a high quality.

The Eevee viewport can be used as a Cycles preview for much work as well. No need for previews: what you see, is what you (more or less) get. Often I have no need to switch to Cycles anymore.

Workflows are changing indeed. The boundaries between real-time and offline rendering are blurring. Good times!

prometheus
11-17-2019, 08:09 PM
Apples and oranges... Each app does it different. If you need a quick render preview Eevee might be helpful as well. Creating a preview in Eevee will be far faster (in particular for animation) than VPR and at a high quality.

The Eevee viewport can be used as a Cycles preview for much work as well. No need for previews: what you see, is what you (more or less) get. Often I have no need to switch to Cycles anymore.
Workflows are changing indeed. The boundaries between real-time and offline rendering are blurring. Good times!

That is a no no, itīs completely different as render engines, cycles will deliver more realistic fluid volumetric renderings than eeve, you can not make a preview render based on eevee, and then try to apply it on to cycles..You need a cycles preview.

Using eeve and itīs render engine for almost realtime stuff, may be good enough for some things though, heck even workbench..though this sample from Chris Jones is perhaps too low in resolution, and I think he could have pushed it more with the shading, even in workbench mode...which he used, and even more with eevee, but it wouldnīt compete fully with cycles...so sample below is workbench, and pretty much realtime rendering.


https://www.youtube.com/watch?v=fRgvqt-YtH4



You say it can be used for previews for cycles, not accurate in my opinion, you can get a fast feedback on some things, but it canīt give you an accurate feedback on the shaders.

You say you do not need to switch to cycles anymore, so have you produced high quality fluid smoke that includes all the bells and whistles of the cycles volume scattering model?

That said, eevee is great..I am not questioning that, or the fact that you yourself do not need to switch to cycles much anymore..but they are not the same..nor is eevee a complete better tool for realistic rendering, if it was...we wouldnīt even have cycle in the eevee release.


I Would like to see some kind of enhanced make preview and play options in VPR, I recall tfd was a bit tedious to work with previews, where cinema4D seemed to have a much better previewer, I think that was specificly made from jascha withing TFD, while Lightwave got no love on that part.


as useal, unfortunately Lightwave will be compared with other preview system, thus..again a blender connection, Iīll try to stop that, I will have to do some post about cycles, fluid fire and smoke, eeeve and old fluids vs mantaflow on blender forums instead, much of my time now goes in to evaluating the old fluid engine VS mantaflow and cycles VS eeve rendering of fluids.


In Lightwave..
I miss some of the old viper preview functions, but there are also functions in the new features that doesnīt have the same kind of effects as in 2015, I loved how we could just fire up hv UI window, apply it on any object, null, or point or particle and easy to set a hypertexture, set a velocity speed hypertexture effect, and we got a nice motion effect going, and you just hit make preview and play directly after to see the effect....not so easy anymore

prometheus
11-18-2019, 12:45 AM
If you look at Blender, what kind of speed improvement do you get on the GPU, maybe 3x?
With faster CPUs coming along, that benefit may dwindle.

I suspect with raytracing hardware coming down the pike, a fully DirectX/OpenGL/Vulcan type of renderer would be better, since it takes advantage of the whole GPU, shaders, transforms, lighting, raytracing, compute, and so on. My 2 cents.

HEY..benifit of blender GPU speed 3x? itīs way faster than that, look at fiberfx CPU render with VPR in Lightwave VS GPU in blender...at least 10 times faster is what it feels like, but even blenders cpu is faster to render hair in blender than lightwaves cpu.
Emission materials in blender VS high luminance surfaces in Lightwave, same there..much much faster in blender, but then again..I am not sure that can be compared properly, using emissive materials in blender is a pure joy, while I just give up on waiting for VPR in lightwave to get anywhere near it.

TurbulenceFD volumetric multiscattering and illuminated smoke, while not Even using PBR volumetrics, horribly slow compared to fluid smoke with Principled volumetric material in blender, and it must be much faster than 3x that time in lightwave.

The simulation speed of fluids at higher resolutions is a different thing though, if using GPU in lightwave and turbulenceFD..it goes faster than blender, that is itīs strength..not the rendering in terms of realism and speed, but that seem to be much faster than in blender with higher resolutions, but I havenīt done any exact matching, but that is what it feels like for a decent quality.

Sensei
11-18-2019, 02:27 AM
cpu+gpu is the way to go.

https://i.imgur.com/XrvJZXi.png

...or make LW renderer in the cloud (Google, Amazon, Microsoft)....

(that would require smart update of assets that have been modified from previous version of scene-to-render to limit Internet bandwidth usage)

Danner
11-18-2019, 03:12 AM
After working with Unreal with raytracing I am sure the future is realtime. (an eevee or Unreal type of renderer) I know some things are not as polished yet, but the advantages of not having to render are just too great to ignore.

vncnt
11-18-2019, 05:39 AM
GPU render speed, realtime raytracing, quality predictability, and CPU/GPU cooperation could be slightly too much to ask for when aiming for enhancements on the existing Preview infrastructure.

So far I've got:

- Undocked Preview Window should be resizeable to fit screen, to enable handling of renders larger than computer screen.
- fix issue to make Undocked Preview Window respect "Show OpenGL UI".
- "Show OpenGL UI" should also suppress SubPatch Cages.
- Add Toggle to Preview Options to force preview to "Hide OpenGL UI".
- "AVI (sound)" should also be available when using Save Preview.
- RGB encoded output.
- fix the AVI index bug that makes the AVI file unuseable in many NLE's.
- fix the issue (codec friendly size?) that makes the output look skewed.
- a single button trigger should start rendering a preview to a file, no questions asked - just coffee.
- Undocked Preview Window should be modeless, to act as a reference.
- Add Save button to Undocked Preview Window, and at least place it in the top left corner if Undocked Preview Window is not resizeable.

More ideas please!

erikals
11-18-2019, 05:51 AM
...or make LW renderer in the cloud (Google, Amazon, Microsoft)....

(that would require smart update of assets that have been modified from previous version of scene-to-render to limit Internet bandwidth usage)

it is actually done as far as i know... LightForge
https://render.lightforge.cc/

gar26lw
11-18-2019, 06:43 AM
I'd recommend someone take a look at some of the stuff in https://renderman.pixar.com/whats-new

prometheus
11-18-2019, 07:56 PM
just got frustrated exactly this moment about vpr not able to be paused, I had it refine some nice cirrus clouds, and yes..I need to let VPR refine it, not final renders for the artistic control, so it was refined to a decent level, then I was about to tidy nodes in the window I worked in for the procedural node texturing, and the VPR started to refresh again, I was planning on taking a screenshot of both the nodes and the vpr window....so this is an example of some frustration of not being able to pause the vpr.

you really have to be extra careful about doing something else with tweaking settings.

vncnt
11-19-2019, 04:57 AM
I'd recommend someone take a look at some of the stuff in https://renderman.pixar.com/whats-new
Is there a specific feature on that page that would translate to an enhancement of our Preview feature and evolve LW towards GPU rendering?

vncnt
11-19-2019, 05:06 AM
just got frustrated exactly this moment about vpr not able to be paused, I had it refine some nice cirrus clouds, and yes..I need to let VPR refine it, not final renders for the artistic control, so it was refined to a decent level, then I was about to tidy nodes in the window I worked in for the procedural node texturing, and the VPR started to refresh again, I was planning on taking a screenshot of both the nodes and the vpr window....so this is an example of some frustration of not being able to pause the vpr.

you really have to be extra careful about doing something else with tweaking settings.
Maybe it's possible to add a VPR mode that updates only the modified materials in VPR.
Not only for a viewport VPR but also for the entire existing Preview.

jwiede
11-19-2019, 07:33 PM
Is there a specific feature on that page that would translate to an enhancement of our Preview feature and evolve LW towards GPU rendering?

There are a couple things mentioned which would enhance LW's Preview feature (f.e. see their mentions around always-live rendering). There's a lot of tech in PR22 around how render caching is handled that would be as useful for LW VPR, to cite one.

You do understand that the "Show OpenGL UI" stuff in and of itself has next-to-nothing to do with "GPU rendering", right? The OpenGL UI mention comes from the existing viewport tech using OpenGL, and thus "show OpenGL UI" is referring to running the viewport OpenGL UI code to draw atop the VPR-rendered surface(s) (in OGL terms). Sure, the GPU is involved in doing the OpenGL drawing, but the "rendered image" that's being drawn "behind" the OpenGL UI is still entirely done using LW's render engine (CPU).

vncnt
11-20-2019, 07:53 AM
I think I should explain what "in the direction of GPU rendering" from my first post means to me because I'm not aiming for a GPU renderer that rivals the Lightwave CPU renderer.

I can live with a slow CPU renderer for final output.
For previews during various production stages, a fast OpenGL renderer will be good enough to generate previews but
it still needs to look as good as possible and it still must be generated as easy as possible.

Implementing a production ready GPU renderer remains the holy grail but I don't expect that to happen in 2020.
Enhancing the available tools would put less pressure on developers.

In LW2019 and earlier, my only option to generate OpenGL video clips is the Preview system but this workflow has issues.

Another example of one of those issues: Anti Aliasing GPU setting is usually kept low or off when working in Layout. For rendering GPU AA should be turned on. Yes, I could change this setting in the nvidia control panel, then render, then turn if off again, but that flow conflicts with my goal "as easy as possible".

Since the "lock to the camera resolution" feature is already there ("Undock Preview Win" and "Use Camera Resolution"), using an Undocked Preview Window seems logical, but manually disabling all OpenGL handles (cages, paths, grid, ...), resizing, cropping, transcoding, is not exactly "as easy as possible". It's cumbersome. It would be logical to implement "Hide OpenGL UI" also in that part of the Layout code.
Also, the Undocked Preview Window is difficult to use with a larger-than-display resolution when all the controls are off-screen, and you need to close the Undocked Preview Window before continue editing - this makes it barely practical to use it as a reference.

So what relatively simple improvements should Newtek add to the Preview system
to generate OpenGL clips that look "as good as possible" for your clients
and "as easy as possible" for you?

Dan Ritchie
11-20-2019, 12:42 PM
I'm on Radeon, so my question is, is it just me? Does PBRGLSL VPR work for everyone else, correctly, I mean?

vncnt
11-21-2019, 01:32 AM
Can you give more details about the problem?
And the age and model of your Radeon card.

Dan Ritchie
11-21-2019, 10:56 AM
Can you give more details about the problem?
And the age and model of your Radeon card.

This is all I get out of PBRGLSL, and I'm on mobile vega, or I can switch to the 560x (polaris) on an Nitro 5 gaming laptop, and I get the same results either way.

146306

jwiede
11-21-2019, 02:57 PM
Presumably you have it set to display normal maps, as the scene annotation mentions?

If so, agreed, that looks quite odd. Are you running recent video drivers?

That's a 2019 content scene, correct? Which specific scene file?

prometheus
11-21-2019, 03:40 PM
Maybe it's possible to add a VPR mode that updates only the modified materials in VPR.
Not only for a viewport VPR but also for the entire existing Preview.

Perhaps making it simpler, I just need pause, and restart to iterate from the latest completed refinement state, just as blender does it, or houdini.
Sometimes I want to save a scene, and it all starts to refresh again and I have to wait, itīs unecessary, and same with just a simple move on a window and it may start to refresh from start again...tedious.

Worleys fprime was nice in that regards that it had just all that pause and re-start from the latest state, I am in fact a little baffled that they havenīt been able to push VPR further after all these years by catching up with what worleyīs fprime did so nicely.

Dan Ritchie
11-21-2019, 03:41 PM
Presumably you have it set to display normal maps, as the scene annotation mentions?

If so, agreed, that looks quite odd. Are you running recent video drivers?

That's a 2019 content scene, correct? Which specific scene file?

yes, Yes, and Dinosaur_WLK_GL.lws. I'm running Adrenalin 19.9.2

Dan Ritchie
11-21-2019, 03:51 PM
yes, Yes, and Dinosaur_WLK_GL.lws. I'm running Adrenalin 19.9.2

146308

jwiede
11-21-2019, 05:59 PM
Can you try turning "Faster Highlights" off? I've seen it, on occasion, produce odd shading when all the refl/refr/trans/lum are also active. Never quite pinned down what was going on, though.

I do know there used to be an issue with how many channels you could have enabled even with GLSL, but I'm not sure if that still applies with PBRGLSL or not. Might want to disable all but, say, Normal Map and Specularity, and then post how it looks? The docs definitely seem to indicate multi-texturing has limits with how many textures can be shown in channels.

Also, does the material for "Dinosaur"-aka-Gojira have anythinhg actually in emission / "Luminosity Channel"? If not, then there's no reason for it to be active. Likewise, unless you have a texture feeding in transparency, there's no reason for Transparency Channel. If there's no transparency, period, then no reason for "Transparency" to be active either.

Just things to try, cutting it down to what's needed also helps remove variables from debugging.

vncnt
11-22-2019, 03:21 AM
Perhaps making it simpler, I just need pause, and restart to iterate from the latest completed refinement state, just as blender does it, or houdini.
Sometimes I want to save a scene, and it all starts to refresh again and I have to wait, itīs unecessary, and same with just a simple move on a window and it may start to refresh from start again...tedious.

Worleys fprime was nice in that regards that it had just all that pause and re-start from the latest state, I am in fact a little baffled that they havenīt been able to push VPR further after all these years by catching up with what worleyīs fprime did so nicely.
I agree with a VPR pause button.
And when releasing the pause status VPR should continue, not trigger a re-render.

May I suggest a second VPR button: "disable all VPR re-render triggers".
Because even the smallest activity in Layout interferes with VPR.

Ok, more ideas for OpenGL Preview rendering?

prometheus
11-22-2019, 04:38 AM
I agree with a VPR pause button.
And when releasing the pause status VPR should continue, not trigger a re-render.

May I suggest a second VPR button: "disable all VPR re-render triggers".
Because even the smallest activity in Layout interferes with VPR.

Ok, more ideas for OpenGL Preview rendering?

Render to disc just as Fprime did, I had use of that when I did some gym renders some years ago, I could show a draft to our salesmen quite quickly, and get his okey..then he in turn had to show a better final image for our clients, so I could just pick it up from the last state and continue refining without having to restart render, thus saving rendertime.
Though the speed of VPR has been improved since then..but it would still be useful I think.

Apart from that I need a checkbox option called, save imagefile/scenename, so if I set that as default, each image save I do, will be matching the very often incremental saves I do, and by looking at the images I can then tell what scene it was..today it is to tedious to go in to the settings and change filename to the same name you have for the scene.

Dan Ritchie
11-22-2019, 10:29 AM
Can you try turning "Faster Highlights" off? I've seen it, on occasion, produce odd shading when all the refl/refr/trans/lum are also active. Never quite pinned down what was going on, though.

I do know there used to be an issue with how many channels you could have enabled even with GLSL, but I'm not sure if that still applies with PBRGLSL or not. Might want to disable all but, say, Normal Map and Specularity, and then post how it looks? The docs definitely seem to indicate multi-texturing has limits with how many textures can be shown in channels.

Also, does the material for "Dinosaur"-aka-Gojira have anythinhg actually in emission / "Luminosity Channel"? If not, then there's no reason for it to be active. Likewise, unless you have a texture feeding in transparency, there's no reason for Transparency Channel. If there's no transparency, period, then no reason for "Transparency" to be active either.

Just things to try, cutting it down to what's needed also helps remove variables from debugging.

Checking or unchecking any or all combinations of the flags makes exactly no difference.

vncnt
11-23-2019, 02:43 AM
Render to disc just as Fprime did, I had use of that when I did some gym renders some years ago, I could show a draft to our salesmen quite quickly, and get his okey..then he in turn had to show a better final image for our clients, so I could just pick it up from the last state and continue refining without having to restart render, thus saving rendertime.
Though the speed of VPR has been improved since then..but it would still be useful I think.

I would like to see this concept enhanced to the entire preview range. Start a VPR render on all frames at once to generate a cache with an image sequence that keeps all images rendered to more or less the same quality level. With the option to gradually "upgrade" the entire sequence, step by step, to a better render quality when the CPU is available.

And would it be possible to only update modified 3D objects on top of existing preview image sequence?
Maybe not even really caring for reflections and GI.
This recycling method could make the 3D industry slightly more environmental aware as a bonus.

Maybe even simpler (dare I say innovative?) method that combines both: send VPR render segments to separate images with variable resolutions.
Then, when the preview is needed on a screen or in a new file, the frames can be reconstructed with the latest version of each frame segement, independently of their resolution. This method could bypass a lot of issues that would arise with a variable upgrade method.

Now I think about it, I've already made a script that devides frames into segments and can generate a Fusion comp to assemble the segments.
But the entire assembly process should be done in Layout automatically.
Also, the script would need hints to only render the "interesting segments", whatever that may be.


Apart from that I need a checkbox option called, save imagefile/scenename, so if I set that as default, each image save I do, will be matching the very often incremental saves I do, and by looking at the images I can then tell what scene it was..today it is to tedious to go in to the settings and change filename to the same name you have for the scene.

vncnt
11-23-2019, 03:11 AM
Maybe even simpler (dare I say innovative?) method that combines both: send VPR render segments to separate images with variable resolutions.
Then, when the preview is needed on a screen or in a new file, the frames can be reconstructed with the latest version of each frame segement, independently of their resolution. This method could bypass a lot of issues that would arise with a variable upgrade method.

Now I think about it, I've already made a script that devides frames into segments and can generate a Fusion comp to assemble the segments.
But the entire assembly process should be done in Layout automatically.
Also, the script would need hints to only render the "interesting segments", whatever that may be.
My current implementation of rendering to segments:
146313

It can't assemble variable image resolutions per segment at the moment but that shouldn't be too difficult.
I'll think about image assembly in Layout.

Dan Ritchie
11-23-2019, 11:25 AM
146308

I'm going to go ahead and call this a bug. Perhaps a bug that only shows up because of the difference in vendor implementation. Something like not clipping negative shading, or something.

I did some more work with this, and found that if I turn off all spherical lights, not quite correct, but much more correct results. At least I can see the other channels like the normal map.

This is the result I get if I turn off every spherical light. It's still too bright.146317

vncnt
11-23-2019, 02:23 PM
Did you turn off the Headlight?

Dan Ritchie
11-28-2019, 01:55 PM
I put it in as a bug. Haven't heard anything from them.