Fstorm render

[Ivan1982]

Hi Savage,

I get what you are saying, this is not "blackmail" like "If you do not implement this...".
I am not leaving anyone with wrong impression, i am NOT saying how everyone should change engines just like that, i am using vray(and probably i will continue using it for now), as customer i am saying what i am missing. Same as i found here on forum how other people express their opinion in similar fashion.
You guys are communicating with users, comparing between more render engines, you are trying to understand what "realistic" means, very commendable. You can talk about passes, bounces and god knows what, your knowledge about your engine surpases mine, that is something you do not need to prove!

I am just asking why would you wait?
Why can't you focus on your product and deliver those crucial things instead of telling us how everything is great. You are right, there is other engines that do not have what GPU_RT has, it is faster than some of the engines and everything you said is true to some degree, but again you are not Fstorm, your company is here 10+ years, i am wrong to expect from you not to fail, i am expecting Vray to evolve into current technology. I know this can't be instant, i just do not want to witness again how you are waiting for someone to rock your chair so you could make more fixes in past year than in last 5 years before that.
That is not fair deal for customers. Similar story was with CPU version and finally when everything was ironed out, it become almost obsolete(how many years are left for CPU??)

Even people that doesn't know anything about 3D are aware of Vray, MAX, Maya... currently there is only few companies out there that have such impact on CGI history as those few.
Take example of how Autodesk is giving BS and everyone sees that, and it is hard to tell them that, if you would ask someone in Autodesk what they think why things are like that, they would say there is nothing wrong with them.
They are industry standard for some time now, you are not able to use MAX on it's own(scary), it is serving more like a container to all those plugins you need to make it work, but they made MAX kinda necessary. That is tricky situation for customers, that doesn't give them immunity to critique though, but they use that opportunity to shaft us on every corner.

Those _____ engines that all people compare to Vray maybe do not compare right now directly in some things and in some they they are surpassing Vray but maybe if there wasn't for them we would still have RT as experimental option, who knows. So everything is intertwined and we accepted it.
Thing is that people invested in vray over the years(same as in MAX), model databases, materials, knowledge... Your company is already in advantage knowing that, i realize i am not the only one feeling a bit frustrated about certain development of things in industry.
Maybe that is why your answer is "I would suggest testing the other GPU ray tracers and use the one that suits you best" but it is not that simple.

[vlado]

Here is a slightly tweaked render (256 min shading rate and 8 AA subdivs to better match your Redshift settings) on the Xeon which came in at 4m 56s, compared to Redshift on the GTX 980 at 4m 50s.
Best regards,
Vlado

[vlado]

Here are the renders with your suggested settings; I also played with the V-Ray settings a bit (min shading rate at 32 and LC retrace at 1.0). For Redshift this brought down the render time to 4m 50s. For V-Ray, it brought it down to 6m 10s. Just for fun, I also rendered the scene on one of our old dual Xeon machines, which came in about 2m 25s. I then lowered the noise threshold to 0.02 so that the render time was about the same as Redshift at 4m 35s.

As you said, the V-Ray settings could be further tweaked slightly for even lower render times.

Best regards,
Vlado

[Donfarese]

Ok; rerendering now...

Best regards,
Vlado

I'm not in front of Redshift right now so I'm just throwing out basically how it should be set up, I would assume you will see the render come in at around 4-5min and cleaner on a 980. From these we can tweak it a bit to get it to under 4min probably.

[vlado]

Ok; rerendering now...

Best regards,
Vlado

[Donfarese]

Vlado that's not really good settings for Redshift, that's why the times are horrible. you shouldn't be using 4/4096 AA, you should be upping the BF num Rays to 2000, set the IC screen radius to 4 and AA should be 4/64 0.01. Also don't forget to add 3000 to the ray reserve memory. I don't know why you changed my settings to get a much worse time and image. The changes you made add actually less quality to the render, going from 5 to 15 bounces you wouldn't even notice the difference. you saw the time I got at 3min and it was really clean.

Your major issue is way to high AA settings and way to Low GI Rays setting, the worst settings you can do for Redshift.

[vlado]

Here is the scene in 2105, 2016, 2017.

Here is my test. I am comparing V-Ray CPU (regular V-Ray renderer, not V-Ray RT) on a super old i7-4771 @ 3.50 GHz against Redshift on a single GTX 980. V-Ray rendered in 10m 20s, whereas Redshift in 11m 45s. V-Ray is more or less default settings, BF+LC, bucket sampler, noise threshold 0.04; Redshift is BF+IC, 15 bounces, 64 GI rays, 4/4096 AA samples with adaptive error 0.01, max secondary ray intensity at 20.0.

There are several notes to be made:
*) The noise in the Reshift image is very uneven - some areas are very clean, others are quite noisy. To clean up the noisy areas, you'll need to fiddle with the settings leading to potentially higher render times;
*) Redshift has artifacts on the curtains;
*) The GTX 980 is not the fastest card out there, but neither is the CPU; there are CPU configurations that are easily 4-5 times faster. Of course, you can certainly stuff more and faster GPUs too into the machine.

I've tested Redshift on full-blown interior scenes too with similar results. Overall, it seems to me that it has gotten slower in this latest release. I've been following the development for quite some time and it seemed much faster a while back. Don't get me wrong, Redshift is a good renderer and if it works for you, then go for it. But V-Ray is not too shabby either, especially considering that it will get even faster in the next builds.

Best regards,
Vlado

[savage309]

@Ivan - I would suggest testing the other GPU ray tracers and use the one that suits you best. If something doesn't work, we usually try to fix it and every feedback is precious.
Just to not leave people with wrong impression about RT GPU - keep in mind that some (or all) also don't have directionality, but also stuff like triplanar, car paint, rounded edges, light select with GI, cached GI, hair, particles, unlimited AOVs (you have to render multiple times), real time active shade without need to restart engine, non-pre baked sss (that uses ton of memory), layered material, physical camera, physically correct materials like GGX (not faked and wrong one), any shader language support, DR, denoiser, OpenCL (that works great on the new RX 480), some even don't have motion blur and many more. And RT GPU does (at the same time being on par of more often a lot faster). I can go on with the list, but I am not sure if there is a point in doing that.
We have a lot of work to do, for sure. We have the procedural bump map support added in 3.4, but I agree we need better bump in general, matte material, fluids and we will get there. RT GPU is very stable, works very well for many and there is a lot of production videos and stills made with it. I also agree that the most frustrating thing is that we share UI with the Adv V-Ray version. This is why we have the * in the docs. Changing this will take more time. Usually it is not that something doesn't work in RT GPU and it does work everywhere else. It is that it doesn't work in RT GPU and it works in V-Ray Adv. Making V-Ray level raytracer is not the same thing as making a raytracer.
I would not agree with the excuses part. Comparing 5 bounces versus a 100 is not excuse, it is like comparing a plane speed with measuring how much it takes to get form NY to Chicago vs from NY to LA. It is a different thing.
@Donfarese - GTX 1080 is supported fully in V-Ray 3.4 and even in the 7 months old V-Ray 3.3. It is a bit faster than Titan X and it will be the case for most scenes for the other raytracers as well. Keep in mind that it is successor to 980, not to the Titan X, so it is a great result. CUDA 8 will change nothing specifically for GTX 1080, since the GP104 is very close to the Maxwell architecture and whatever CUDA 8 changes will affect the Maxwell GPUs as well.

Best,
Blago.

[Donfarese]

These actually look pretty damn close if not identical with the Normal map I applied, but as you can see as another issue I run into is when you feed Vray RT a Bump or Normal map you also run into these weird sharp shadowing a lot of times on the objects.

[Donfarese]

Hi Ivan1982, I'm thinking your issues with the 1080 is just that, it's the 1080 and it's not really fully supported correctly in most or all GPU renderers until the DEV's get there hands on Cuda 8.0. I could be wrong though.

I do agree with you that I hope they focus more on Vray RT now. But you always have Vray CPU which is a really great renderer.

[Donfarese]

For me...it's seems that the material proprerties are different...how you can compare them?
What do you like? a more reflective material with an higher IOR in fresnel reflection with more roughness (Vray one) or a lower IOR fresnel reflection with less roughness (RS one)?

If properties are comparable, probably the shader model is different...becasue it's clear that are 2 different material.

Really, it's difficult to understand the point...

The point is Bardo that when testing with other GPU Renderers most all of the results match the Redshift version, and that is the look I was trying to get, I didn't just add materials and say what ever it look like I'm going with it.

[Ivan1982]

Thanks for files.

I don't know how did you get those times in vray, it is around 5min 10sec and proportionally higher in Redshift but faster than Vray. Titan X shouldn't be that much faster than 1080.

Around 1min30sec for 6x1080.

You have introduced VrayRT before redshift(not sure about Octane) but lost 3-4 years doing basically nothing to move your GPU_RT up to priority ladder, even though it was clear GPU will be future and now it looks like you are finding million excuses on every forum thread vray vs any other GPU engine.
You should admit to yourself that there is few render engines out there that are more advanced(finalized), much faster, with more supported features out of the box(i am talking features of render engine itself, not 3rd party plug-ins) today is Fstorm, tomorrow who knows, Should you be in phase Company vs "little guy"?

I am using Vray for 10 years and i will continue using CPU version as long as it is viable investing lot of money for 5-10% performance increment every 3-4 years(yea you have to like Intel) and as long as perf per $ is ok. You need to come to your senses, this generation of GPUs is 50% faster than previous, much more cost effective and more promising, i think people are interested about what you will do with GPU version, as they do not want to give 3k$ for one xeon when they can buy 5-6 top GPUs for that money.
No one is asking here for one click "photoreal" solution or to be fastest... but currently GPU_RT shouldn't be called rendering solution without *. Don't act surprised when people start talking how is something better than vray right now, most of the people are not rendering grey interiors for sake of benchmarking, they do not want to talk on forums how MSI is set on 20, explaining difference between QMC vs DMC, clamping, sub pixel and all kind of other technical stuff while not being able to render volumetrics, or if bump on their material looks awful... I would never imagine that would be that hard to implement feature simple as directional light(maybe i am wrong but that looks like simplest stuff to do), even if that makes it slower than competition at least it will be supported, you can always tweak it later, it is much better than to end up in situation not being able to use it at all, like now.

Having about 10 render engines that are not compatible will make future years problematic in terms of investing in hardware, software and knowledge i just hope we won't end up in situation, one render engine for refraction, one for reflection, one for diffuse one for volumetrics and so on... that would be absurd.

*not complete solution

[vlado]

@bardo We did have some issues with bump mapping in V-Ray GPU specifically. There are no issues on the CPU though.

Best regards,
Vlado

[bardo]

For me...it's seems that the material proprerties are different...how you can compare them?
What do you like? a more reflective material with an higher IOR in fresnel reflection with more roughness (Vray one) or a lower IOR fresnel reflection with less roughness (RS one)?

If properties are comparable, probably the shader model is different...becasue it's clear that are 2 different material.

Really, it's difficult to understand the point...

[Donfarese]

So you're willing to compromise, severely so, on quality (see your above diffuse renders: the blackness got every single slightly shaded area. Fine by you, fine by me.) for the sake of argument?

Because, you see, while you CAN clamp V-Ray (go ahead. i shall not do that to it. guts churning at the thought.), and get quicker rendertimes, you cannot unclamp RS, and when 15 bounces of GI are too few, you're done for.
When you're using IES lights and trying to sell an accurate lighting distribution in your scene, you're (by default) screwed, or if the intensity of something has to be above 1k float (lights, probes, you name it), you're screwed, and so is your lighting distribution.
If you need reflective GI caustics well resolved and contributing to your lighting, all you'll get will be fireflies, unless you clamp hard and clamp early.
When you want to comp, you're by default outside of linearity within the radiometric equation itself because of all the clamping, so you guessed it, you're screwed as far as LWF comping is concerned.

It's not faster, it's ridiculously more messy to set up and get results from, it's severely more limited in features, it's broken in a number of places, but you like it.
What can i say, go ahead.

peace out. ^^

Hey Lele, I always respect you for your knowledge and help. Don't ever hold back what you think that's the way people learn, even if it's the hard way. But my issue is not with speed, Both Vray RT and Redshift are fast, if I was only concerned with speed I'd just Use IC + IPC in Redshift and render in 1/5th the time of Vray and Cleaner. The major issue I find with RT is not getting what you expect, as far as shader or features, Don't get me wrong it's amazing, but with say Octane render, or Redshift when I'm creating I usually get the look I was after, or am able to render what I need. I've had quite a lot of issues rendering scenes with RT or not being able to render scenes in RT, and I put them in the forums in the past. Below is one example of a very quick render of a material, the Redshift version is exactly the look I was trying to get, the Vray version I couldn't get it to look right. Maybe I'm just bad at Vray