If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
Exciting News: Chaos acquires EvolveLAB = AI-Powered Design.
To learn more, please visit this page!
New! You can now log in to the forums with your chaos.com account as well as your forum account.
I just converted my interior V-Ray to Corona scene, back to a V-Ray scene. I did the bad and installed the beta right in the middle of a project, and it renders much faster. I am talking, 4X faster. I am first doing in with V-Ray Advanced and then I'll test with GPU.
Btw, Bobby, just to be sure I got it right, 3.50 was 4 times faster compared to V-Ray 3.4 or compared to Corona ?
Also, make sure to test V-Ray GPU in 3.50 Beta 2 (Beta 1 didn't had Adaptive Lights).
looks really fast but however sadly stil not as fast as the gpu renderers out there, i also hate the way how the scene clears in vray, idk something about it just seems so buckety, but stil i love this speed increase i see, seems this new update changes the game for vray abit
Testing 3.50 here shows that it is not as fast as the other GPU renders as well. But thats because 3.50 is faster.
As usual, if you have any problem scenes - send them over and we will fix them.
There is "the feeling" that V-Ray GPU updates slower (is not as interactive) - and this is true for some setups. One of the reasons for that is that we don't keep the frame buffer on the GPU and we transfer it all the time to the CPU. But this is a feature - allows rendering of huge resolutions (since it we don't allocate memory for the pixel buffer), allows single pass render elements and runtime (during rendering) denoising. We like that feature a lot and we don't plan on changing it.
Testing 3.50 here shows that it is not as fast as the other GPU renders as well. But thats because 3.50 is faster.
As usual, if you have any problem scenes - send them over and we will fix them.
There is "the feeling" that V-Ray GPU updates slower (is not as interactive) - and this is true for some setups. One of the reasons for that is that we don't keep the frame buffer on the GPU and we transfer it all the time to the CPU. But this is a feature - allows rendering of huge resolutions (since it we don't allocate memory for the pixel buffer), allows single pass render elements and runtime (during rendering) denoising. We like that feature a lot and we don't plan on changing it.
Best,
Blago.
wish there was the option to switch and not transfer anything to cpu for some scenes when not rendering huge scenes, and yeah if it updated like in fstorm or octane i think it would be really nice, its apart of the wow factor for me, started to not like them buckets i used to dream of buckets man! coming from my days on dual core slow machines
"Testing 3.50 here shows that it is not as fast as the other GPU renders as well. But thats because 3.50 is faster."
I am not sure I understand this.
That was to @mitviz - I am saying that 3.50.02 was faster with the scenes I tested compared to other raytracers, and that if there are scenes were it is not, all you have to do is send them over and we will fix that.
Btw Bobby, which material was not supported ? I want to fix that.
wish there was the option to switch and not transfer anything to cpu for some scenes when not rendering huge scenes, and yeah if it updated like in fstorm or octane i think it would be really nice, its apart of the wow factor for me, started to not like them buckets i used to dream of buckets man! coming from my days on dual core slow machines
We do bench the final frame times.
Interactivity/feedback can be better (and is a bit better in 3.50.02), but it never has been that bad. But I admit it is not perfect, but is this really where you feel we should invest (not overall performance and features that make rendering easier and more powerful, but hiding buckets and updating the VFB quicker after camera change) ?
If you have a scene that we can test with that feedback speed, that will be nice.
That was to @mitviz - I am saying that 3.50.02 was faster with the scenes I tested compared to other raytracers, and that if there are scenes were it is not, all you have to do is send them over and we will fix that.
Btw Bobby, which material was not supported ? I want to fix that.
Best,
Blago.
hmm ok, how to do that, usually i like to just make a one go at it in whichever renderer, i will see about something and send you a scene if i can, maybe its something i have been doing wrong with RT all along
hmm ok, how to do that, usually i like to just make a one go at it in whichever renderer, i will see about something and send you a scene if i can, maybe its something i have been doing wrong with RT all along
Just mail it to blagovest.taskov@chaosgroup.com. If you want we can provide FTP to upload it at, but if you have something easier for you (google driver, dropbox, wetransfer, etc) it is fine as well.
But I admit it is not perfect, but is this really where you feel we should invest (not overall performance and features that make rendering easier and more powerful, but hiding buckets and updating the VFB quicker after camera change) ?
In my case interactivity in context is much more important, since that is where I spend active time. During rendering I can do something else. I don't think it is because of their final render time Fstorm, etc is generating so much interest.
Comment