Generating intellectual discussion on renderers - non-attack mode :)

Become a member of the CGSociety

Connect, Share, and Learn with our Large Growing CG Art Community. It's Free!

REPLY TO THREAD
 
Thread Tools Search this Thread Display Modes
  12 December 2017
Originally Posted by oglu: if thats the case  they should jump on redshift..
its just not what we need at the moment... 

i wont post rendertimes... if someone needs a comparison only for speed do it by yourself..n
Ok it isn't what you need at the moment, but it is what dozens of others need.
If you are up to huge racks full of dual xeon machines sucking power for rendering and cooling and also waiting hours per frame ... then sure you don;t need redshift
If you want to get fantastic interaction during lookdev phase and also have couple render nodes replace 30-40 cpu render nodes... heheh

So why is the issue posting time per frame as well?
If you are offering comparison so it could even help someone decide why not giving full picture?
Oh yes render A is the best of all of them.. (*small print* ofc you will need to plan couple months of rendering alone, and forgot about multiple versions, once it is on farm that is it no time for changes) 
__________________
www.cgfolio.com

Need some help with rendering an Redshift project?
http://www.gpuoven.com/
 
  12 December 2017
fast answer... i dont have time to bring them all at the same noise level... 
throwing out some numbers wont help...

edit:: and i need directionality for area lights in redshift...
at the moment the lighting is a bad hack in the redshift scene...
__________________
ArtStation
 
  12 December 2017
Originally Posted by oglu: fast answer... i dont have time to bring them all at the same noise level... 

hehe - honestly, this was the dead ringer for me - a comparison has already been done between those 4 renderers on a more difficult to clean Interior scene....and its not even close.  You can render an Animation of the Interior scene with Redshift in the time it takes the other 3 engines to reach the Single Frame noise level of Redshift.
 
  12 December 2017
For crying out loud, Redshift is a one trick pony. It's fast and that's about it. Seems like nobody mentions the very very bad way of doing ambient occlusion AOV. I let it slide, but for those people who are so excited that is fast, do the following:
Make some nurbs objects, they can be pimitives, I don't care. Render them with redshift. Is it possible? Of course not. While I understand the industry moved away from nurbs, there are situations were nurbs were the best solution. So from my point of view your fastest renderer alive is actually crippled from the start. Not to mention it lacks the flexibility a general purpose renderer should have.
So we all agree, it's fast, we get you, ok? Some of us simply don't care, because speed is not always a good measure of performance.
Most renderers are fast if the scene management is good. Granted, not as fast as a GPU renderer, but decent times in the hands of those who know their jobs. This is why not everybody is falling on their back when they hear "fast rendering"
__________________
the one button to render them all
 
  12 December 2017
if redshift takes care of 99% of production needs and do that much faster and better then others, who cares about nurbs or similar stuff that is never used. 
Keep nurbs and render in hours, or convert them to poly and render in seconds hehehe
You are also pointing to your personal needs and that redshift is not good because of those. 
Redshift users are also pointing same thing, it is best for our needs and honestly to the needs of most productions out there. 
It is not JUST fast.
So you point one thing that is not supported properly and that majority of people are not even using.. so what.. keep using other renders but you can't say that whole render engine is not good because it isn't supporting one niche thing that doesn't really matter much.

Finally.. all those other renders are being developed for how many years now? Redshift just recently was in alpha.. and look where is it now.

It is not point to start flame wars as it was asked at the start but doing comparison render and don't showing numbers and admit that render speed is one of important parts of render engine.. that is just silly. You can easily have all frames hand painted to the level of  photo realism.. it will take weeks for each frame but hey it looks great and there is nothing that painter can't make, nothing is unsupported
Hehehe render farm consisting of 100s of painters, painting frame by frame. Take that redshift!
__________________
www.cgfolio.com

Need some help with rendering an Redshift project?
http://www.gpuoven.com/
 
  12 December 2017
the list for me is longer...
we need xgen interactive...
an up to date ss shader...
directionality for area lights...
and something like cryptomatte...

and yes i kow all of that is in the works... but that doesnt change my decision thats now nothing for us... doesnt mean this will change in the next year ot two...
__________________
ArtStation
 
  12 December 2017
Originally Posted by mirkoj: if redshift takes care of 99% of production needs and do that much faster and better then others, who cares about nurbs or similar stuff that is never used. 
 Well, it's only a bit faster, whoopty doo. It also lacks the flexibility some other renderers have. I say it's only a bit faster, because if you don't have many GPU's the speed is not that great. Granted, the preview is good, but once you want to have a noiseless image the rendertimes go up. It's good that is good for you, use it. Don't be surprised when some other people are not that happy with it. 

Originally Posted by mirkoj: Redshift just recently was in alpha.. and look where is it now.
As you said, the things it's lacking are too niche to bother with them, I suspect they will never bother with it, unless they do a version for Rhino or something similar.

Originally Posted by mirkoj: It is not point to start flame wars as it was asked at the start but doing comparison render and don't showing numbers and admit that render speed is one of important parts of render 
I don't intend to start a flame war. I just point out redshift  can become useless in some circumstances. It's really not the only renderer with half assed features. Maya Paint effects should have been in mental ray, that was a request asked on several occasions. Mental ray added partial creases to subdivision surfaces only recently and there is no 1 to 1 parity in the crease levels in other renderers and let's not even start with Arnold's rendertimes. So every renderer is crappy in some way, there is no flame war here.

It actually reminds me about the endless comparisons between REYES  and raytracing. In every single test a REYES renderer like renderman performed much better, but they never bothered to mention that the rendertimes were without any rays cast. So faked mirrors and faked GI. Great, people came to the very wrong conclusions that renderman = fast and mental ray = slow. But in any real life scenario everything got a lot more complicated. If you remember, renderman used to have almost instant displacement mapping, 15 years ago - basically faster than redshift today and this is exactly the trick with "fast"; not knowing the whole story can trick you into false assumptions and lead to bad decisions.
I see the whole discussion regarding redshift as history repeating itself with a few differences - I told you, I understand is way faster than CPU renderers, but still worth pointing out the shortcomings of every renderer. In fact, I think is much more important to know what every renderer cannot do, so one can decide to use it or not. There is so much marketing hype with everything the last we need is fanboys who will promote their choice without taking a minute to think about the bigger context.
__________________
the one button to render them all
 
  12 December 2017
Like I said before...its all about time per-frame to noiseless image...Speed Kills everything else.  Now Redshift will be even faster per-frame.

 
  12 December 2017
well when render engine don;t have speed it has to focus on some other PR and other selling points
__________________
www.cgfolio.com

Need some help with rendering an Redshift project?
http://www.gpuoven.com/
 
  12 December 2017
Originally Posted by TwinSnakes: hehe - honestly, this was the dead ringer for me - a comparison has already been done between those 4 renderers on a more difficult to clean Interior scene....and its not even close.  You can render an Animation of the Interior scene with Redshift in the time it takes the other 3 engines to reach the Single Frame noise level of Redshift.
Might I bother you for a link or such to that comparison?!
Thanks!
__________________
..je suis -L -S -D!
 
  12 December 2017
Originally Posted by Leionaaad: For crying out loud, Redshift is a one trick pony. It's fast and that's about it. Seems like nobody mentions the very very bad way of doing ambient occlusion AOV. I let it slide, but for those people who are so excited that is fast, do the following:
Make some nurbs objects, they can be pimitives, I don't care. Render them with redshift. Is it possible? Of course not. While I understand the industry moved away from nurbs, there are situations were nurbs were the best solution. So from my point of view your fastest renderer alive is actually crippled from the start. Not to mention it lacks the flexibility a general purpose renderer should have.
So we all agree, it's fast, we get you, ok? Some of us simply don't care, because speed is not always a good measure of performance.
Most renderers are fast if the scene management is good. Granted, not as fast as a GPU renderer, but decent times in the hands of those who know their jobs. This is why not everybody is falling on their back when they hear "fast rendering"
Custom AOVs came yesterday. Nurbs, i have not seen them in a serious production environment at last 5 years.
We are running a studio based based on houdini and redshift and know several others doing the same, so what on earth are you doing where you feel that it lacks in flexibility. I have to say it lacks in comparison to mantra, but then you are talking pretty advanced stuff that most mortals dont have to deal with.

If you really want to attack redshift go for the stuff where it actually does struggle and that is massive data sets.
It also needs some adjustments to the shading model and texture filtering, really hard to get textures crisp.
 
  4 Weeks Ago
@pokoy,   don't need to feel that I am 'cannibalising' MR as I am not the reason for the dismissal.  
I can say 'non-attack' mode -- I can use any term I like in a forum as a matter of my freedom of speech. 
No doubt, I write for cebas as their social media person, and prefer not to start a cannibalising thread
as this is a sensitive topic. First, if you like, be invited to take a peek at finalRender, right? No one can
force anyone to buy anything - but the dev team is working hard as you are working hard as an artist. 
So that's what I mean, non-attack mode. Either way, I have not said anything derogative about other 
renderers and never will. And I don't need attacking comments either. It's my personality, nothing to do
with cebas. You are not going to now order my boss to make me into a personality you like, right? 
 
  4 Weeks Ago
@CerberusC -- thank you for letting me know about Blender Cycles. 
 
  2 Weeks Ago
Fast depends on the user.

"Fast" now typically means how quickly it takes to get an image of any kind (first pixels) and update changes. Traditionally "fast" meant how long to converge. When talking about speed it's important to categorize the two. "Got an image I could use for decisions/changes in 20 seconds" versus "Got a final frame I can use in 3 hours, 22 minutes" Actual timing is pretty irrelevant, like, "22 minutes versus 53 minutes" because everyone's machine and personal threshold are different. It might make more sense to say, "This image is 35% faster than this other image".

A sphere on a plane test is now completely silly as performance in renderers is aimed at solving complexity and benefits of new technology won't really kick in until you try something reasonably complex. In fact, your sphere on a plane performance will continue to degrade while scenes you never thought possible before will become a few button clicks away. And while final speed is still important, I'm finding more and more people are interested in getting their image ready to render more quickly and care much less about how long that final render takes. Your $1500 PC can cook overnight or send it to a cloud service. Previously those options were prohibitively expensive or non-existent.

Rasterizers are going to win the speed race for a final frame. If you want fast then you'll eschew raytracing in favor of more manual setup/labor if you require photorealism. Since hardware has gotten so much better, you're seeing an explosion of renderer options based on raytracing. No longer do you need complex or clever trickery from the days when mental ray and RenderMan dominated, now you can brute force a solution and let the hardware do the work. Everyone is moving this way as the hardware gets better. Even older methods like biased rendering are easier to tune, not because the technique is better, but because you can crank up settings and let the hardware do the work instead.

The machines and the labor have become commodities. You can buy more hardware and cheaper artists and this fuels the number of renderer options out there. So your choice is probably going to be influenced by your capital because most renderers will give you what you need with a few exceptions. As a reminder, many films from the 1990's still hold up well despite using techniques most people would snort at today. So "it can't do..." doesn't hold up for most comparisons except maybe one or two. One of these is scalability. Many feature films have shots where the data easily exceeds 100s of GBs in displacement, textures, and more. This is where capital and software requirements meet. Not every renderer off the shelf can do that yet effectively, nor are they designed to based on their target industry. Chances are most of you in here don't need that (at least not consistently).

Side note: the A.I. densoiser from Nvidia is not yet designed for final frames, it's designed to improve interactive feedback during progressive rendering. They freely admit that in this version.

There's also a lot of misunderstanding about what exactly happened at Autodesk with regards to mental ray. Autodesk was in charge of the plugin for the majority of its time. They decided what to ask for in features and what to expose. (It took, what, 3 years to expose Unified Sampling officially?) They were risk-averse and wanted to avoid spending money on support for new features. Before Nvidia purchased mental images, there was already a new version of mental ray being tested with techniques you still can't find in off-the-shelf renderers. There is a VFX studio using many of these techniques now. Autodesk passed on integrating it and Nvidia buried it since it was based on the CPU after acquisition. C'est la vie....

Bart is currently interested in supporting mental ray users as well and may even have opportunity in a new future of sorts: https://forum.nvidia-arc.com/showth...ers-and-support

Eventually Autodesk got what they wanted, their own renderer in Arnold and a reset from years of self-imposed stagnation (they had tried to buy RenderMan and mental images at some point years ago). M&E is their least revenue-generating line of products, and while it's very important to those of us where it's a career, for Autodesk it's by far not their moneymaker industry and there will continue to be a market for existing and new renderers going forward for users needing specialized workflow or results.
__________________
My opinions are always my own...and maybe a friend's, but never my employer's.
 
reply share thread



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
CGSociety
Society of Digital Artists
www.cgsociety.org

Powered by vBulletin
Copyright ©2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump
Miscellaneous

All times are GMT. The time now is 08:50 PM.


Powered by vBulletin
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.