PDA

View Full Version : Octane> fast?... not so sure...



erikals
09-18-2010, 07:31 AM
 
2 hours rendertime,
http://www.refractivesoftware.com/forum/viewtopic.php?f=5&t=3536

20 minutes rendertime,
http://www.refractivesoftware.com/forum/viewtopic.php?f=5&t=3554

5 hours rendertime   (living room image)
http://www.refractivesoftware.com/forum/viewtopic.php?f=5&t=3521


from what i understand it is fast and good as it produces no GI flickering, so it's good for certain animations.
but realtime?... certainly not.

 

erikals
09-18-2010, 07:45 AM
 
also check "GPU vs CPU" by Brad Peebler,
http://www.youtube.com/watch?v=4bITAdWvMXE

 

walfridson
09-18-2010, 08:01 AM
 
also check "GPU vs CPU" by Brad Peebler,
http://www.youtube.com/watch?v=4bITAdWvMXE
 

sponsored by intel? :)

erikals
09-18-2010, 09:14 AM
 
intel "inside" :]

 

Captain Obvious
09-18-2010, 09:42 AM
 but realtime?... certainly not.
I don't think anybody's ever claimed that Octane is real-time. It's updating in real-time, sure, but the whole idea is to have progressive refinement la FPrime. Oh, and Octane does seem to be a heck of a lot faster than, say, Maxwell or Fry.

Nicolas Jordan
09-18-2010, 10:42 AM
I have never had much faith in the GPU approach. I like the CPU approach of renderers like FPrime. Octane seems like a fun toy at the moment and may turn into something more useful in the future but I personally like having my renderer as part of the program I am doing most of my work in. I have never liked the idea of external rendering programs that you have to bring stuff into to render.

cresshead
09-18-2010, 11:15 AM
interesting...

iray which should be out for 3dsmax by the end of sepetember is bruteforce i believe but can use cpu and gpu on a render..i'll report back on it's usefulness when it arrives.

so far VPR on Lightwave 10 looks the most interesting way to go.

IRAY 3DSMAX DEMO
http://www.youtube.com/watch?v=PosKRTgAlIo

Soth
09-18-2010, 01:50 PM
http://www.youtube.com/watch?v=zbokPe4_-mY

cresshead
09-18-2010, 03:05 PM
http://www.youtube.com/watch?v=zbokPe4_-mY

meh!:D

seemed REALLY REALLY REALLY slow considering it had 80 cores!

cresshead
09-18-2010, 03:16 PM
http://www.youtube.com/watch?v=nhXBx8l0iso&feature=related

I like the 'ray brush' so a user can determine important areas to get resolved first to check a scene.

cresshead
09-18-2010, 03:25 PM
RTT usa delta gen

http://www.youtube.com/watch?v=WUwXOs4pcjM&feature=channel

Soth
09-18-2010, 03:51 PM
meh!:D

seemed REALLY REALLY REALLY slow considering it had 80 cores!
yap, but its http://en.wikipedia.org/wiki/Unbiased_rendering - so its the program that you can start doing photo realistic renderings after one day of learning.

cresshead
09-18-2010, 04:29 PM
yap, but its http://en.wikipedia.org/wiki/Unbiased_rendering - so its the program that you can start doing photo realistic renderings after one day of learning.

you mean just the same as Iray? :)

zero learning curve with iray, ies lights and A/D material library...just drag n drop realistic materials on to models place ies lights..just make it to realword scale and hit the render button with the minimum u.i. for rendering...[note there IS and advanced tab rolled up n that vid btw!]

of course that's the marketing speil!

i'll let you know how it plays out once iray is in my subscription folder ready for downloading.

Soth
09-18-2010, 05:37 PM
you mean just the same as Iray? :)
Great, I've missed that iray is physically correct too. :)

Red_Oddity
09-18-2010, 07:15 PM
My tests with iRay where very very disappointing, though i had to hack it all together with the dlls from the standalone MentalRay installer and telling Maya to render MentalRay with iRay via render scrips (because per Autodesk tradition, the things they mention in the manuals and their shiny marketing hype actually is never fully implemented or works default out of the box.)

But iRay is a multitude slower than Octane on the same hardware with our tests.


Also, GPU renderers will probably find their own niche market, my biggest bet is this will be pack shots for print or commercials.
And what people forget is that those render times are the refinement render times, but when working with Octane you have a fully rendered scene in a couple of seconds, that is the biggest plus.

erikals
09-18-2010, 08:26 PM
...but when working with Octane you have a fully rendered scene in a couple of seconds, that is the biggest plus.


how can that possibly make sense considering the rendertimes i posted in post #1...?

Captain Obvious
09-18-2010, 08:29 PM
I have never had much faith in the GPU approach. I like the CPU approach of renderers like FPrime. Octane seems like a fun toy at the moment and may turn into something more useful in the future but I personally like having my renderer as part of the program I am doing most of my work in. I have never liked the idea of external rendering programs that you have to bring stuff into to render.
None of this has anything at all to do with GPU vs CPU rendering, though. There is no technical reason for why it would be impossible to have a GPU-based final rendering solution built into your 3D animation package.



yap, but its http://en.wikipedia.org/wiki/Unbiased_rendering - so its the program that you can start doing photo realistic renderings after one day of learning.
"Unbiased" does not mean "based on more accurate physical models". It's a statistical term.

Elmar Moelzer
09-19-2010, 05:29 AM
And what people forget is that those render times are the refinement render times, but when working with Octane you have a fully rendered scene in a couple of seconds, that is the biggest plus.
That is the same case with VPR and Fprime. So not really a thing that is specific to Octane, or Iray.

Exception
09-19-2010, 10:37 AM
So, that luxology video was totally useless... a 12 Core computer with modo pitted against a 2 core GPU Octane, and that is supposed to tell us something? I don't think so.

Also, this 80-core video is funny. They call it real time, but it clearly isn't rendering at 24 fps, just updating real time. Fprime can do that, and it doesn't need 80 cores to do it :) I also love how somehow having an IOR for a material is proof of it being 'scientifically accurate'.

A GPU is a useful tool in the box, and can calculate complex math. Thus, it can be used to accelerate renders. How that is then implemented will determine performance.

LW_Will
09-19-2010, 10:38 AM

intel "inside" :]



his pocket...

;-)

Lightwolf
09-19-2010, 10:47 AM
So, that luxology video was totally useless... a 12 Core computer with modo pitted against a 2 core GPU Octane, and that is supposed to tell us something? I don't think so.
A fermi has up to 448 (usable) cores...


A GPU is a useful tool in the box, and can calculate complex math. Thus, it can be used to accelerate renders. How that is then implemented will determine performance.
And that is precisely the problem. It comes with a massive number of caveats that must be overcome first.
Even just generalising by calling it "the GPU" in this case is a problem, as every generation has different tradeoffs that make a big difference on how to approach problems (and certainly as lot more as opposed to, say, different CPU generations that may even come from different vendors).

Cheers,
Mike

Lightwolf
09-19-2010, 10:48 AM

intel "inside" :]

As opposed to being sponsored by nVidia? ;)

Cheers,
Mike

LW_Will
09-19-2010, 10:59 AM
As opposed to being sponsored by nVidia? ;)

Cheers,
Mike

True. I think the one take away from this is that INTEL says you cannot implement the same code on a GPU that you would run on a CPU. NVIDIA says that their GPU's are massively parallel for raw computational speed.

They each are trying to sell a "solution"; CPU or GPU.

What some clever software engineer needs to do is to work out the software correctly and to heck with the hardware people.

course, that engineer will charge a small moon full of gold for the privilege but hey, its capitalism.

cresshead
09-19-2010, 11:36 AM
i think the hybrid approach is the best way to use CPU and GPU together.

Elmar Moelzer
09-19-2010, 11:56 AM
i think the hybrid approach is the best way to use CPU and GPU together.

Please entertain me a bit as to how this super hybrid approach works.
So far I am having trouble following. I do have a few ideas to make it work, but really it is always a bit of hack and all solutions that I can think of, have their limits.

cresshead
09-19-2010, 12:13 PM
Please entertain me a bit as to how this super hybrid approach works.
So far I am having trouble following. I do have a few ideas to make it work, but really it is always a bit of hack and all solutions that I can think of, have their limits.

well i'm no porgrammer!
but it's surely better to use GPU and CPU rather than just one OR the other.

that way you get the advantages of both for what they are good at.

Iray seems to do this Hybrid approach, once i have it running i'll report back on just how useful it is...i'll need to get a new graphics card anyhow as my current card in my quadcore is just a cheapo game card:2guns:
:lol:

probiner
09-19-2010, 12:44 PM
Oh i had no idea there wasn't a solution in nowdays for both CPU and GPU work on a renderer...
Since we see videos games, where the graphic card and the processor are both intesevly used, i thought the same would happen for a joint renderer.

What are the issues?

Cheers

LazyCoder
09-19-2010, 01:23 PM
The way a video game renders and the way we're talking about rendering are two very different things.

The faster way video games are rendered isn't physically accurate. Distortions in water are usually just pixel shaders, whereas the physically based rendering is actually calculating how the rays disperse.

I have no clue how any of that work tbh... lol

Elmar Moelzer
09-19-2010, 01:57 PM
but it's surely better to use GPU and CPU rather than just one OR the other.
Whenever you have to transfer data back and forth between the GPU and the CPU, you run into problems. Transfering data from the GPU to the CPU is particularily problematic. So in fact, it is better to do just either or.

Games do not really count, because they do not really compare to a renderer like Iray, Octane, or VPR.

I can give you examples from volume rendering, which is what I have to concern myself with all the time:
We do both GPU raycasting and CPU raycasting in VoluMedic. The CPU raycasting integrates very nicely into the LW renderer. In fact, most of the time, you wont even notice where the volume rendering starts and the LW rendering ends. The GPU raycasting is currently running the OpenGL viewport. It is fast, but it has its limits.
1. Integration with LWs own Polygon OpenGL Rendering. It is currently not possible to correctly render intersections with LWs OpenGL rendering. There may be a way to do this via the z- buffer, but we have not had time yet to look into it. In any case, there will be issues with transparencies with this solution. You can not effectively combine a rasterizer and a raycaster.
2. Multiple volume objects. They work wonderfully in the software renderer, but are very problematic in the raycaster. You can not just do a z- blend between two semi transparent volumes...
3. Integration of the GPU renderer with the software renderer is again only possible via the Z- Buffer. You can, unfortunately not calculate a sample on the GPU and then send that to the CPU renderer for integration, or lets better say, you can not do it fast enough.
Again, this is an example for "all or nothing". Either everything is done on the GPU, or nothing, or you will loose the advantages of the GPU.
4. Memory limitations. You can not just upload part of a scene to the GPU and forget the rest, especially not when raytracing. There are some tricks you can do (and Mike knows them too), but as I said, whenever you have to put stuff on the GPU or get stuff from the GPU, things will get slow.
So again, it is an "all or nothing" situation.
5. Let me give another example that is speciffic to our code. In VoluMedic, we have a feature called Volume Painting. It basically allows you to directly paint into the volume with a volumetric brush. Since this feature has an Undo History, it is very memory intensive. It is no problem for us to update the CPU rendering in realtime, whenever the user makes a brush stroke (currently via VIPER, but I hope soon in VPR). Now I would have to reupload the entire dataset to the GPU every time the user makes a brush stroke, which takes a few seconds.
Another feature that we have are the Selection Masks (basically a user defined volume that acts as a "volumetric alpha channel" for the dataset. Same problem there. It is not possible to update them in realtime on the GPU, it will always take a few seconds to update the dataset on the GPU to the current state.
Or I do the entire volume painting on the GPU. Now with only 1 GB of RAM on most current graphics cards, where do you put all the data for your Undos? Of course when you want to save the changes you have made to the dataset on your harddrive you would also have to download the entire data from the GPU memory to the main memory. Lots of issues here.

So if you want to do GPU rendering, you have to do everything on the GPU in order to maintain the speed advantage of the GPU. Otherwise you may just as well keep everything on the CPU and have no limitations.
That would mean that every shader, every texture (also procedural textures) and every shader plugin, every filter plugin, would have to be calculated on the GPU and of course it would have to be speciffically written with the GPU in mind.
So you can not just take code X and feed it the GPU. It does not work like that.

You dont have to take my word for it. I have just returned from a meeting at the local university. I talked to some of the world leading people for GPU volume rendering there. Their entire work is about getting everything done on the GPU (including the things I mentioned above). They will tell you about the challenges. They also will tell you that you can currently only do this using CUDA and Nvidia Fermi cards (IIRC).
So you have even more problems for a real world app here.

Red_Oddity
09-20-2010, 05:03 AM
how can that possibly make sense considering the rendertimes i posted in post #1...?

Yeah, i should have made that line a bit more clear.
I meant, with a progressive renderer you pretty much get an immediate result of what the final render will end up like unlike a 'traditional' renderer that processes an entire image before showing, however, you will still need the a fore mentioned render times to get to a somewhat clean / final result.

Hieron
09-20-2010, 05:21 AM
That is not limited to GPU renderers though. Fprime has it a long time already and Core VPR etc seem to go way beyond that again.

Personally I'm quite enthusiastic about those CPU based progressive renderers. This GPU hype so far seems based on quite little.

Referring to Brad Peeblers video: it would be nice to have a better use of the renderfarm during testrenders sometime.. keeping it up to date with the scene info on the main workstation means it constantly needs data transferred I guess, but for some shots that take a while to refine, it could be well worth it. That I would like to see and that would mean a little hype for me.

I guess Modo is closest to that right? Hence Brad's "test-will-probably-never-hit-the-market-but-showing-you-anyway".

Elmar Moelzer
09-20-2010, 05:44 AM
Also dont forget that the CPUs are still improving their speed according to Moores Law. In a couple of years, you will be able to buy twice as much CPU power for half the price and all that on a single chip. So you will basically be able to have four of your current workstations in one.
I may be wrong, but looking at Nvidias performance in recent years, I dont quite see such a steep improvement here.
The 480 is not THAT much faster than the 285 was (and that one has been arround for a while) and it is also quite expensive.
The 460 is roughly the same speed as the 285.
So, I am not too impressed with the speed improvements/price in recent years.

Lightwolf
09-20-2010, 05:54 AM
The 460 is roughly the same speed as the 285.

Single precision, yes (and the the 285 seems to have fewer memory alignment issues).
Double precision, nope. But then again this is where nVidia cripples and differentiates its GPUs at the moment (low cost consumer cards have a much lower dp performance compared to Quadros and Teslas).

Cheers,
Mike

Elmar Moelzer
09-20-2010, 05:57 AM
Double precision, nope.

Ok, you have got a point there. I forgot about the improvements there, but then I always only think about consumer cards (I see no point in spending thousands of USD on a graphics card). Yes, the whole Quadro and Tesla thing is a really bad move by Nvidia. It will cost them even more market share. They have already been loosing big time to ATI lately.

Lightwolf
09-20-2010, 06:30 AM
Yes, the whole Quadro and Tesla thing is a really bad move by Nvidia. It will cost them even more market share.
That depends on the market... They currently pretty much own the HPC market for GPUs. Low volume, high profit...

Cheers,
Mike

Elmar Moelzer
09-20-2010, 06:37 AM
They currently pretty much own the HPC market for GPUs. Low volume, high profit...

Ok, true, but this is a very small market niche. Dont forget that. I agree though that they dominate this part of the market. I doubt that a lot of LW users would buy into it though. Where is the advantage of using the GPU, when you have to shell out enough money to buy a medium sized CPU- renderfarm for the money?
Nvidias Tesla has only come out and Intel has already started shipping their new architecture, Sandy Bridge. The performance of these (lower mid end) CPUs is very impressive. I know that it is not part of Intels roadmap right now, but if/when the high end parts also get updated performance like that, you are looking at some serious CPU- power there. Even the low end parts rock and cost very little.

lardbros
09-20-2010, 07:02 AM
well i'm no porgrammer!
but it's surely better to use GPU and CPU rather than just one OR the other.

that way you get the advantages of both for what they are good at.

Iray seems to do this Hybrid approach, once i have it running i'll report back on just how useful it is...i'll need to get a new graphics card anyhow as my current card in my quadcore is just a cheapo game card:2guns:
:lol:

I've looked at a lot of that Iray stuff, and even on the architectural, internals of a building demo, the update is pretty darn slow. Yes, it may be quick with a sphere on a plane, and even if that sphere is shiny (oooooh, nice) and the plane is also nice and reflective (ooooooh)... it stays nice and quick... BUT if it's like most things that are added to Max recently, they sound incredible on paper, but when you come to use it in production they fall flat on their face.

Iray will be good, but so far, VPR seems like a better solution, especially the speed of it so far. Just hope that Autodesk get Iray up to speed... when does Iray get released anyway? We're on subscription too, but feels like there hasn't been an update for aaaaages!!!

Lightwolf
09-20-2010, 07:10 AM
Just hope that Autodesk get Iray up to speed...
Wouldn't that be mental images, erm, I mean nVidia? ;)

Cheers,
Mike

Exception
09-20-2010, 10:33 AM
A fermi has up to 448 (usable) cores...

Apples and oranges.


And that is precisely the problem. It comes with a massive number of caveats that must be overcome first.
Even just generalising by calling it "the GPU" in this case is a problem, as every generation has different tradeoffs that make a big difference on how to approach problems (and certainly as lot more as opposed to, say, different CPU generations that may even come from different vendors).

Yes, that is all true. But it's still a tool in the toolbox. If someone finds good use for it in the render pipeline, more power to them. I just havn't seen it materialize very well so far, but I would be surprised if you can't derive some benefit from it.

Elmar Moelzer
09-20-2010, 10:39 AM
I just havn't seen it materialize very well so far, but I would be surprised if you can't derive some benefit from it.

Best use is as a replacement for the OpenGL preview.
I would not use it for the final rendering.

Lightwolf
09-20-2010, 10:40 AM
Apples and oranges.
Precisely, which is why your initial remark is just as far off ;)
Interestingly enough AMD will also make it a bit harder to differentiate the difference between a logical core and a physical core in their next-gen CPUs.


Yes, that is all true. But it's still a tool in the toolbox. If someone finds good use for it in the render pipeline, more power to them. I just havn't seen it materialize very well so far, but I would be surprised if you can't derive some benefit from it.
I've seen some cases where it made sense, i.e. within the Avatar pipeline at WETA or for fluids.
Neither of these are generic cases though, but that's precisely where GPUs have their problems, generic cases.

Cheers,
Mike

lardbros
09-20-2010, 11:13 AM
Wouldn't that be mental images, erm, I mean nVidia? ;)

Cheers,
Mike

Yeah, true...

the Devil is in the details! ;) I should have been clearer ;)

Red_Oddity
09-20-2010, 12:24 PM
I've looked at a lot of that Iray stuff, and even on the architectural, internals of a building demo, the update is pretty darn slow. Yes, it may be quick with a sphere on a plane, and even if that sphere is shiny (oooooh, nice) and the plane is also nice and reflective (ooooooh)... it stays nice and quick... BUT if it's like most things that are added to Max recently, they sound incredible on paper, but when you come to use it in production they fall flat on their face.

Iray will be good, but so far, VPR seems like a better solution, especially the speed of it so far. Just hope that Autodesk get Iray up to speed... when does Iray get released anyway? We're on subscription too, but feels like there hasn't been an update for aaaaages!!!

So far from our tests, VPR is a lot faster than Iray (tested with the BMW Z4 model, on 3 levels SubD and some nice car shader like shading in a HDR lit scene), but as mentioned before, i had to use the dll's from MentalRay Standalone to get it to run in Maya, so i have no idea if that has any impact on performance (tested both CPU and GPU rendering in Iray)

Cageman
09-20-2010, 01:13 PM
Oh i had no idea there wasn't a solution in nowdays for both CPU and GPU work on a renderer...
Since we see videos games, where the graphic card and the processor are both intesevly used, i thought the same would happen for a joint renderer.

What are the issues?

Cheers

There is one renderer out there that does take advantage of both CPU and GPU when rendering. It can also take advantage of CPUs and GPUs of networked computers to render a sequence or a still.

http://www.randomcontrol.com/arion

probiner
09-20-2010, 01:18 PM
There is one renderer out there that does take advantage of both CPU and GPU when rendering. It can also take advantage of CPUs and GPUs of networked computers to render a sequence or a still.

http://www.randomcontrol.com/arion

thanks

the squary pattern in the beginning looks more like modo/vpr, but then refinement looks like fprime.
http://www.randomcontrol.com/downloads/showreels/arion/arion_tech_demo_003.mov

cresshead
09-20-2010, 02:47 PM
sounding like a broken record....

Iray uses CPU & GPU...together.
:)

lardbros
09-20-2010, 03:06 PM
sounding like a broken record....

Iray uses CPU & GPU...together.
:)

It does yes. According to the docs you get better speed increases using the GPU over the CPU... doesn't say much about using them both at the same time, but it is definitely possible. It can also be used on the CPU on its own.

Glendalough
09-20-2010, 03:10 PM
SmallLux GPU (part of the Luxrender development) is a hybrid renderer using both CPU and GPU at the same time.

Captain Obvious
09-20-2010, 06:03 PM
There is one renderer out there that does take advantage of both CPU and GPU when rendering. It can also take advantage of CPUs and GPUs of networked computers to render a sequence or a still.

http://www.randomcontrol.com/arion

Arion seems to suffer horribly from the same problems that Octane (at least the earlier versions) and Maxwell 1.0, though, with white speckly noise in certain scenarios. In one of the sequences in the "lego" scene, it's been rendering for six seconds and you have a good estimate of the scene, but if my estimates on noise levels are correct, you'd actually be looking at about 30-40 minutes for a full HD frame of that thing "noise-free" quality. While that's probably faster than Fry Render, it's not really that fast and I'm certain that you could achieve the look your after in significantly less time with a biased, not-based-on-physics renderer like FPrime, LW, Vray, Kray, modo, etc.

Elmar Moelzer
09-21-2010, 01:09 AM
sounding like a broken record....

Iray uses CPU & GPU...together.

Yeah, but to what extent and to what benefit for the user? How much faster is it actually when it does that? These are the questions you should ask. Also what does "together" mean?

cresshead
09-21-2010, 01:11 AM
Yeah, but to what extent and to what benefit for the user? How much faster is it actually when it does that? These are the questions you should ask. Also what does "together" mean?

i'll let you know in 9 days time...once it's in our download areas on the subscription Advantage pack!:hey:

Exception
09-21-2010, 02:04 AM
Precisely, which is why your initial remark is just as far off ;)

I think that's exactly what my initial remark was trying to say: apples and oranges. The comparison doesn't fly. So the movie is pretty silly. :)

Captain Obvious
09-21-2010, 02:19 AM
I think that's exactly what my initial remark was trying to say: apples and oranges. The comparison doesn't fly. So the movie is pretty silly. :)
No, it's not. It's a perfectly relevant comparison: top of the line GPU with a GPU-based renderer, vs top of the line CPU with a CPU-based renderer. The only way to compare performance across different platforms is to compare products with similar cost, or heat, or whatever else you might find relevant.

And the idea with that video was not to show that GPU rendering sucks, or that Octane is slow, but rather it demonstrates that even though GPU rendering is viable and a hell of a lot faster than CPU-based, it's only really doable with brute force path tracing, which is inherently slower to begin with. CPU-based rendering with lots of clever tricks is going to end up being faster anyway in many cases.

cresshead
09-21-2010, 03:11 AM
i'd also add into this the cost

12 core cpu based computer
Vs
an nvidia graphics card or maybe 2 cards...

are they the same cost?:hey:

then cost vs performance

JonW
09-21-2010, 03:32 AM
In one of the sequences in the "lego" scene, it's been rendering for six seconds and you have a good estimate of the scene, but if my estimates on noise levels are correct, you'd actually be looking at about 30-40 minutes for a full HD frame of that thing "noise-free" quality.

The Octane benchmark (lego) scene takes about 5 minutes to render to good quality & get rid of the last few white noise in the shadow areas. This was on a GTX280 which is not a bad card even today.

Rendering the scene in LW to what I feel to be the same quality took about 2 minutes. Ok, this was on a pair of X5580 CPUs. But even these are getting long in the tooth.

I also like having truck loads of ram, & actually like doing renders within LW. Although it would be nice if in LW you cook the render & stop & start it & save copies at any time.

So at the end of the day at lease for this scene they render in about the same time whether on CPU or GPU. Im also not going to buy a box full of graphics cards because all my other programs only need one card. If there was a ten fold or more improvement then that would be interesting.

Hieron
09-21-2010, 03:33 AM
Anyone used Octane on a big true production yet, and willing to share details? Big studios shifted en masse yet?
I can't, since our scenes are too big to fit into the tiny ram. We use plugins and volumetrics it doesn't support and the cached biased GI is blazing fast compared to it brute forcing.

But by all means, please do share actual experience here. Got 15 - 20k invested in our current hardware, if the GPU will make it 25x faster that money, sure I'd buy.

The shots Erikals came up with was also my experience, useless to us.....

*edited post for niceness* :)

Glendalough
09-21-2010, 03:47 AM
The thing about the GPU renderer is not so much the speed issue as at the moment the materials, surfacing, shaders etc are very limited. You would have to design a scene specifically with this in mind.

Hieron
09-21-2010, 03:56 AM
The renderer is already really fast on my GTX285 for product viz shots. Certainly much faster than brute force GI in LightWave and modo using my aging Q6700. ;)

Octane is a great renderer, but it is best for relatively simple scenes like product viz, a single car or similar stuff like that. The gallery is a good showcase for which scenes types fare best with Octane.


Ok, I wouldn't doubt for a second a GTX 285 can out brute force an old Q6700. But why brute force it in the first place? Don't get me wrong, I love the interactive part, just like other interactive renderers. But wouldn't all those scene fare pretty well with cached/biased GI? Does Octane cache the brute force solution? Making fly throughs superfast after it is cached? If it doesn't and the client asks for a flythrough of those arch viz scenes, wouldn't your workflow get smashed?

Is it just a faster version of Fprime, with more constraints? (I believe Fprime uses some tricks though) Then I don't get the greatness. Yes the interactivity is great but it's not like the LW renderer is like it was when Fprime launched.

Ah well... I'm looking forward to a *smart* interactive renderer, Core VPR comes to mind and looks amazing. Vray RT too, but they didn't port it to LW yet and I didn't port myself to supporting aps yet :)

Captain Obvious
09-21-2010, 04:03 AM
i'd also add into this the cost

12 core cpu based computer
Vs
an nvidia graphics card or maybe 2 cards...

are they the same cost?:hey:

then cost vs performance
A couple of high-end Quadros will cost you more than a 12 core blade.

Red_Oddity
09-21-2010, 04:09 AM
i'll let you know in 9 days time...once it's in our download areas on the subscription Advantage pack!:hey:

Yes, let use know, because in our tests is was OR the GPU OR the CPU, not both, whenever Iray found a Cuda compatible card, CPU usage would be 0%.

But again, we tested it in a pretty much crippled workflow.

Hieron
09-21-2010, 04:30 AM
hmm Neverko, you are right about that. Usually I solve it with an AO buffer but I guess brute forcing it is an option in that case.

How does Octane cope with lots of transparant objects and refractions/reflections (blurred)? Afaik, LW doesn't use too much smartness there so some of our shots get slow. How does Octane cope with those, in your experience compared to LW? (using tricks to stup blurring after bounce 2 or so, using nodal panel..)

Glendalough
09-21-2010, 04:32 AM
Octane uses a spectral light model (like Fry and Maxwell) instead of traditional RGB rendering...

So then is this the special quality that gives the 'unbiased' look that only a few engines have? That is without getting into an argument about the exact definintion of 'unbiased' and also 'physically based' or 'physically accurate', I mean only a handfull of these renderers have this look (basically Maxwell like).

Elmar Moelzer
09-21-2010, 04:46 AM
but rather it demonstrates that even though GPU rendering is viable and a hell of a lot faster than CPU-based
See, this is where I am not too sure.
1st, you cant just go and render any surface on the GPU. So you would have to do custom surfacing in order to render LW scenes on a GPU. This is something you have to understand. Sure some of LWs basic surfacing would probably work nicely, but most would not. Also in order to make use of the spectral light model, you need surfaces that are made for this sort of rendering. So again, new surfaces would have to be made. Also, most Node Surfaces would probably be to complex for the GPU to handle.
You would also have to do the volumetrics on the GPU, of course. So those would have to be rewritte for that as well.
Also, speed will change really, really quickly once you hit the memory limit of the GPU, which can happen sooner than you think...
Take all that into account and you compare the real life speed advantage of the GPU, over the CPU and you really have to wonder whether it is worth it. Also consider how fast the CPU rendering could be if you restrained everything the way you have to do with the GPU. Limiting yourself like that can allow for some really big optimizations.
Basically it is a tradeoff. You can do certain things very well and very fast, but you loose the flexibility that you have with CPU rendering, where you can literally throw anything at it and get a result (more or less quickly).
A Core i7 940 CPU, costs about 250 USD now. Buy two of them and you have 8 physical cores or 16 threads. A Core i7 940 costs 800 USD. Also not really that expensive compared to high end Quadros that have a good amount of RAM, which you can get for a Dollar and a Dime on the CPU.
Anyway, it is a tradeoff. I think both have their values, but you have to decide for either or. You can not have both.

lardbros
09-21-2010, 05:15 AM
There are of course limitations... it's very interesting reading the docs on Iray actually... if you listen to what Autodesk is saying and how they were marketing it at Siggraph, they were boasting about an interactive previewer of 3ds max mental ray scenes.

If you read the docs written by Mental Images, it's a different story. They are very frank and honest about the whole deal, and do openly say "iray is not intended as an interactive preview-mode for mental ray and it is not a real time ray tracer (RTRT). iray allows for an interactive scene navigation mode utilizing fast but necessarily approximate interim calculation of the images".

They also say this:
"Rendering performance is always heavily dependent on scene content and complexity, so it is not possible to give a general answer to this type of question. However, when coupled with a modern NVIDIA GPU, iray should be able to produce renderings with a heavy emphasis on full global illumination and subtle light effects substantially faster than the current mental ray software renderer executing on a single desktop configuration. In cases where general global illumination effects are not required, the current mental ray software rendering mode may continue to be faster and more flexible."

Elmar Moelzer
09-21-2010, 05:25 AM
There you go, right from the horses mouth.

erikals
09-21-2010, 06:32 AM
neverko, hint,..

in Modeler cut out the area that needs detail into a new layer.
in Layout, choose that layer and go to object properties where you can add customized GI settings with better quality.

(it's not always a solution, but sometimes)

Captain Obvious
09-21-2010, 06:51 AM
If you have objects like cellphones and stuff like that with lots of small insets and detail I often struggle to get rid of (interpolated) GI splotches around the small details in LightWave and modo.
Kind of off topic, but in modo you can actually assign different GI methods to different shaders. By assigning a special shader to small detail areas, and forcing them into brute force mode, you can get really good quality with balanced render times. It works better than Lightwave's object-specific where you can only change settings like number of rays. However, Lightwave's final gather mode with interpolation turned off can give you a really good balance between speed and quality.

Hieron
09-21-2010, 07:18 AM
Kray has it too right, surface based settings of GI mode and options..
Would be great to have in LW native for sure.

Cageman
09-21-2010, 07:53 AM
Kray has it too right, surface based settings of GI mode and options..
Would be great to have in LW native for sure.

LW has object based GI-overrides so with what Erikals mentioned, you should be able to achive good detail in smaller parts of an object without having to apply insane settings for the complete scene. It does mean that you have to split the object up into more layers, but until (or even IF) LW get surface based GI-overrides, this method is a pretty good one in most cases.

:)

probiner
09-21-2010, 12:11 PM
LW has object based GI-overrides so with what Erikals mentioned, you should be able to achive good detail in smaller parts of an object without having to apply insane settings for the complete scene. It does mean that you have to split the object up into more layers, but until (or even IF) LW get surface based GI-overrides, this method is a pretty good one in most cases.
:)

It only become a bit tedious if you have to split SubD surfaces and create clipmaps for the surface holders, but other than that, yah, straight forward.

Exception
09-21-2010, 12:35 PM
No, it's not. It's a perfectly relevant comparison: top of the line GPU with a GPU-based renderer, vs top of the line CPU with a CPU-based renderer. The only way to compare performance across different platforms is to compare products with similar cost, or heat, or whatever else you might find relevant.

We'll have to disagree on this one. First, the engines are not the same, so that's already another paramter in the test that's off. Second, one engine has been much longer in development than the other. Third, the GPU method is itself a relatively young use of technology and the GPU's themselves are hardly mature for this type of application.

I don't see that as any proof that using the GPU is not a good idea to implement as either an assist or main engine for raytracing. The stuff we do now on GPU's in modern games we were doing on CPU's 10 years ago. I think this might be a definite trend. I look forward to the day I can do my visual raytracing on the GPU, and leave my CPU to deal with fluids, dynamics and other varieties of support calculations.

Lightwolf
09-21-2010, 12:47 PM
I look forward to the day I can do my visual raytracing on the GPU, and leave my CPU to deal with fluids, dynamics and other varieties of support calculations.
Which is interesting as GPUs are currently better suited to what you call support calculations (and that's also where they're heavily used - as the limitations are otherwise to big for "production" rendering).

Cheers,
Mike

erikals
09-21-2010, 12:57 PM
well, hopefully some coders can prove to the world that the GPU pitfalls can be efficiently fixed...
until then...

http://www.newtek.com/forums/showthread.php?t=112296

 

Exception
09-21-2010, 01:35 PM
Which is interesting as GPUs are currently better suited to what you call support calculations (and that's also where they're heavily used - as the limitations are otherwise to big for "production" rendering).


Sure, other way around is equally fine. I'm not arguing about one way or another. Right now I have this piece of processing power in my computer that sits there doing nothing as my images render. I see potential to put that in use. I can see how its hard to use the CDROM drive in the process, but the GPU seems to have some potential at least.

Captain Obvious
09-21-2010, 04:54 PM
LW has object based GI-overrides so with what Erikals mentioned, you should be able to achive good detail in smaller parts of an object without having to apply insane settings for the complete scene.

The main problem is that interpolation *NEVER* works well on certain things, and in Lightwave you cannot choose method on a per-object base only density of samples, number of rays, etc.





We'll have to disagree on this one. First, the engines are not the same, so that's already another paramter in the test that's off. Second, one engine has been much longer in development than the other. Third, the GPU method is itself a relatively young use of technology and the GPU's themselves are hardly mature for this type of application.
You misunderstand the purpose of the video. The purpose is to demonstrate that the GPU is no magic bullet automagic make-go-fast machine. Largely because the only algorithms that make sense to implement on the GPU are the ones that are inherently slow anyway.




and leave my CPU to deal with fluids, dynamics and other varieties of support calculations
I can't remember which film studio it was, but I remember reading about this one project where they ended up simulating AND rendering on the GPU. The only way to get it doable was to calculate everything on the fly, otherwise the overhead of sending data back and forth became so big that just pure CPU was faster.

Exception
09-21-2010, 04:59 PM
You misunderstand the purpose of the video. The purpose is to demonstrate that the GPU is no magic bullet automagic make-go-fast machine. Largely because the only algorithms that make sense to implement on the GPU are the ones that are inherently slow anyway.

I don't think I said I thought it was automagic bullety thinghy stuff. :) Would be cool if it was, but things that are too good to be true generally are. :)

Cheesecake can be too good to be true though, so there's at least that... :D

Lightwolf
09-21-2010, 05:10 PM
I can't remember which film studio it was, but I remember reading about this one project where they ended up simulating AND rendering on the GPU. The only way to get it doable was to calculate everything on the fly, otherwise the overhead of sending data back and forth became so big that just pure CPU was faster.
That was the fluid simulation developed by ILM for the Last Airbender.

It wasn't the only way doable... but the only way to really leverage the speed of the GPU to actually have an impact on production times. Mainly because it allowed for more iterations to get the simulation to look just right.

They still had to integrate the results into their software renderer for the rest of the plate.

Cheers,
Mike

erikals
09-21-2010, 05:35 PM
yup, they did that for Harry Potter too for the spinning flames :]
http://www.youtube.com/watch?v=hY3TN7YlHUY#t=7m27s

 

Captain Obvious
09-21-2010, 08:09 PM
I don't think I said I thought it was automagic bullety thinghy stuff. :) Would be cool if it was, but things that are too good to be true generally are. :)

Cheesecake can be too good to be true though, so there's at least that... :D
You misunderstand me again. :p

Basically, the point of the video is not to show a fair comparison between Octane and modo. It's to demonstrate that everything isn't automagically faster on the GPU, as some people — not you — seem to think.

Exception
09-22-2010, 01:29 AM
Basically, the point of the video is not to show a fair comparison between Octane and modo. It's to demonstrate that everything isn't automagically faster on the GPU, as some people not you seem to think.

Perhaps, but that's not the message I got from it. That movie basically said to me: see it doesn't work, aren't we great for not putting tons of development in this. Everyone's stupid, we're smart, kind of thing.

Then again, I do get that feeling with most of Mr P's messages.

Hieron
09-22-2010, 02:28 AM
Didn't Nvidia acquire Mental Images or something.. surely if somebody can come up with a good GPU renderer, it must be them?

Talking about stuff not doing anything in your pc: My GPU isn't doing much when I am traversing our big arch viz scenes. The single threaded whatever it is is maxing out and can't supply the GPU with enough data.

That's a 4ghz i7 btw..

Is that "fixed" in Core? Because it is annoying that my GPU isn't stretching its legs, ever.

Lightwolf
09-22-2010, 04:09 AM
Didn't Nvidia acquire Mental Images or something.. surely if somebody can come up with a good GPU renderer, it must be them?
See for yourself: http://livesmooth.istreamplanet.com/nvidia100921/ - scrub to 55 minutes for an iRay demo.

Cheers,
Mike

Soth
09-22-2010, 05:23 AM
A couple of high-end Quadros will cost you more than a 12 core blade.

But Quadro seems to be much more expansive than Xeons. I am testing Arion here too and if 2/4 2GB GFX 460 cards will render at least few times faster than CPUs only (Xeons) then I might consider adding it to my farm... and people will be able to render animations with it.* I just checked couple of scenes only and I am having some small isues - but I will let you know soon how it goes.

ThereGPU rendering have many restrictions that people do not know about, it is not only memory limit, another one is 64 textures, 128 surfaces per scene. Yes you can use one texture on many models but the whole point of rendering with brute force on graphic cards with unbiased renderer is to get things done with less work on human side not more...


* - It is quite funny as Maxwell renderer demoreel is composed mostly from stills moving from right to left... LOOK guys! We managed to render still that have 20% higher resolution than this video file! Everyon else is rendering animatios? Sorry, we are not there yet. :D

Hieron
09-23-2010, 11:22 AM
See for yourself: http://livesmooth.istreamplanet.com/nvidia100921/ - scrub to 55 minutes for an iRay demo.

Cheers,
Mike


Hey thanks for linking that. Interesting ofcourse, also the 32 Fermi by webbrowser thing. But well.. in the end it says nothing sadly. Speeds are all hard to derive..





* - It is quite funny as Maxwell renderer demoreel is composed mostly from stills moving from right to left... LOOK guys! We managed to render still that have 20% higher resolution than this video file! Everyon else is rendering animatios? Sorry, we are not there yet. :D



:) I smiled a bit at Maxwell Render video gallery too :)

Soth
10-03-2010, 01:32 PM
so I finished some tests:

NVidia GTX 460 is about 40% of the speed of two X5650 (12cores,24 threads, 2.66"2.93w/turbo). So you can boost your system 160% - that if you will put 4 of those cards in the case.

If you want to build render nodes then according to my calculations GPU system is (roughly) 3-4 times cheaper (render node with one i7 + 4xGPU), but (as we all know) much less flexible.

But, if you can learn RandomControl tools (those are very easy to master) and you are using 3D only for visualisations (any sort) then you can save a lot of money on render farm and workstation (not to mention that your workstation will generate previews much faster and that will speed up work).

But that is based only on Arion. There is so many renderers that are not there yet and I have absolutely no way to check out Octane as it does not have CPU only mode/version.

So bottom line is - it is faster but we have not (as many would like to think) discovered philosopher's stone. :D

JonW
10-03-2010, 04:00 PM
Attached is a quick Lightwave set up. The lighting is different (It seems to have strange lighting in the original scene).

Soth
10-03-2010, 05:08 PM
I hope you don't mind me posting this on YouTube: :)
http://www.youtube.com/watch?v=Zqfj0535hQk

JonW
10-03-2010, 05:28 PM
No. If one is to invest in new products you have to do research & compare. You need to be able to render the same scene (or at least similar) with different products.

In the LW scene there is a “front light” set up with needs Diffuse & Specular turned on, The render is a little longer.

Danner
10-03-2010, 05:48 PM
I was so unimpressed with th IRay presentation.. they are in awe of something we have been doing for years. With that much hardware behind it I was expecting real time photoreal not progresive render with errors.. (did anybody else catch the checkerboard on the vase shadow?)

lardbros
10-03-2010, 05:59 PM
The iray demo was impressive compared to the actual use of it... I've been trying to get something useful and fast out of it for a few days, and it is soooo limited in its use, I won't be replacing mental ray for a while. Admittedly it's only version 1, but it's a poor show compared to the version 1 of VPR in LW.

I realise and understand these are two completely different engines doing two different ways of rendering, but iray is a massive disappointment, and VPR is very exciting. The amount of catch 22s using iray is beyond a joke... in fact every new feature in 2011 'Advantage' (as they call it) is full of catch 22s... hmmmm, i wonder when they'll learn that it's good practice for all of what has come before to work, even a little bit, in your latest renderer.

Newtek are doing good things in this department, atleast area lights are working in VPR and most of the nodes. How hard would it have been to implement the standard materials into iray? Hmmmm!

Lightwolf
10-03-2010, 06:06 PM
I've been trying to get something useful and fast out of it for a few days, and it is soooo limited in its use...
I'm glad it's not just me...

Cheers,
Mike

lardbros
10-03-2010, 06:17 PM
Certainly not just you... It makes me glad in a way, but the marketing and hype was tremendous... Siggraph was demoing it on a 32 Nvidia tesla server, or machine with 3 Firmi cards in (and it was still slow on the firmi machine)... nothing but mass hype and hysteria, which is a shame as i thought render previews would be coming to Max, but nope!!

My machine at work isn't slow either, and when I get my 12 core, Firmi machine in a few weeks I'll let you know if it's any quicker... I doubt it though.


The 3ds max docs made me laugh too though... the example of a render done in 1 minute (ok... it was ropey at best, but only had a minute)...

then the shot after says 'after an hour' and it's still grainy as hell...

then, after 4 hours... and guess what, it's still grainy. VERY grainy.

Wish I could find the document, but the autodesk website is pretty poor for helping me find any evidence of crapness, so I'll have to leave the embarrassment to someone else to find.