GPU Render

[Ilidrake]

Wasn't sure where to post this so I posted it here as I will be refering to AM.

 

GPU rendering. Is it faster and if so are there any plans to incorporate this feature into AM? If it was implemented I would pay a little extra to get the functionality. I think GPU rendering, if faster, would be worth more on the over head price of AM.

 

...any thoughts???

[robcat2075]

Wasn't sure where to post this so I posted it here as I will be refering to AM.

 

GPU rendering. Is it faster and if so are there any plans to incorporate this feature into AM? If it was implemented I would pay a little extra to get the functionality. I think GPU rendering, if faster, would be worth more on the over head price of AM.

 

...any thoughts???

 

It's faster when it's faster, but not if it's not.

 

There have been two serious runs at GPU rendering for A:M that I know of.

 

When the first GPU rendering scheme came out ("Gelato") Martin says they tried to implement it but it was never faster than what A:M did already and NVIDIA wouldn't answer their technical questions about how to make it work better.

 

Steffen tried again for V17 using OpenCL but said it wasn't reliable and what worked wasn't much faster.

 

Perhaps the OpenCL software will improve in the future to make it more feasible.

[John Bigboote]

Thats interesting, Rob. I didnt know A;M had a history of RND on this. Wasnt Arctic Pigs and HA:MR GPU based? Some of us are experimenting with exporting obj sequences to Element 3D where a fast render includes realtime AO, DOF, glow, refraction and other goodies... But LACKS raytrace features like reflections and shadows... Which is a huge negative in my book.

[robcat2075]

Thats interesting, Rob. I didnt know A;M had a history of RND on this.

Martin told me that the situation with NVidia was unworkable. If they asked a question on NVIDIA's Gelato user forum they wouldn't get an answer and if they went the official support route they had to pay some huge chunk of cash upfront to pose the question and if the answer to the question was "we don't know" the money wouldn't be refunded.

 

Wasnt Arctic Pigs and HA:MR GPU based?

 

Those were GPU based like A:M's shaded render is GPU based.

 

Some of us are experimenting with exporting obj sequences to Element 3D where a fast render includes realtime AO, DOF, glow, refraction and other goodies... But LACKS raytrace features like reflections and shadows... Which is a huge negative in my book.

 

No shadows? What good is that? Geez, A:M is faster if you turn off the shadows.

[robcat2075]

Here's an idea. Find out what the Octane people would charge to create a plugin to integrate Octane with A:M. Then bargain them down... and then do a Kickstarter to fund it, with the provision that the plugin itself is free, it doesn't add to the cost of an Octane license purchase.

[jakerupert]

Good idea generally, but I believe the Octane people wont have the time and resources for that.

They will make it up for the major players first as their priority.

 

But it seems, they wont charge anything and help out, when the specific comunity does it for

themselves (see like for c4d or blender).

So maybe the best way would be to kickstarterfund the most effective workingpower of some

Softwareguru around here like Steffen or Fuchur?

(In fact an implementation would mean a really huge kind of "update" for A:M)

 

Also: the envidiasituation you described was many, many years ago by now.

They will be probably much more helpfull nowadays.

Else the octane people would hardly have been succsessfull in their endeveaur.

[Fuchur]

I cant help there much, but yes I see the potential... (I am a webdeveloper with advanced skills in PHP, JavaScript and MySQL and quite basic skills in Java and C, but not with C++ which A:M is written in.)

 

But I would not go for Octane... While it is a nice renderer, it only support Nvidia-Cards and that is a no-go for me. There are alternatives of course, like the Indigo-Renderer or even more promising Luxrender.

 

Indigo-Renderer is more used in an architectual context and is a little more expensive but is a full blown ready to use openCL- and Cuda-based renderer.

Luxrender is free and uses the GPL-license with a C++-API, has a currently developing OpenCL implementation (useable by Nvidia and ATI-cards) and is a nice looking renderer.

 

So if I could vote (which I can not) I would vote for Luxrender to be connectable to A:M. It is available for Windows and Mac (and Linux, so that is not that important for A:M).

OpenSource and free for commerical usage means no license-prices and no additional costs for A:M users. Sounds like a great deal to me.

 

We will see what the future brings... It could be a great addition, if it can be combined with A:M.

 

See you

*Fuchur*

[robcat2075]

For me to be interested it would have to be a turn-key addition... you don't have to retexture or relight a scene for this other renderer.

 

How much faster are these for an exactly equivalent render? They aren't instantaneous. Has anyone compared?

[jakerupert]

>While it is a nice renderer, it only support Nvidia-Cards and that is a no-go for me.

 

 

 

 

>be connectable to A:M

 

Therfore I would "vote" for a full "plug-in" octane integration.

[Fuchur]

>While it is a nice renderer, it only support Nvidia-Cards and that is a no-go for me.

>be connectable to A:M

 

Easy: I dont own a Nvidia-Card but only ATI-graphic cards as many other people do too and creating a "feature" which can not be used by 50% (or more) of the users (since ATI is often faster for games and is often less expensive people like to buy AMDs) while there is an alternative which can handle both manufacturers, it is just a logical choice for A:M to use something that helps potentially 100% of the users instead of 50%.

 

In general I like standards better which are supporting as many systems as possible. CUDA has advantages (tends to be a little faster) but it just has too many disadvantages in the other direction and OpenCL has other advantages too (for instance you can access CPU-power with the same commands too, which is not possible with CUDA), it is widely useable, etc.

 

See you

*Fuchur*

[Xtaz]

I'm a Octane user and the plugins works equally for all apps.

 

For each frame since Octane haven't a timeline:

 

1- Transforms the scene to OBJ format and save it

2- Opens Octane Render

3- Loads scene

4- Renders Scene

5- Saves it as PNG

6- Closes Octane

 

I believe to write a plugin like this to A:M isn't hard. See, I'm not a programer

 

In this topic I used one of my models to test the render speed.

[jakerupert]

Easy: I dont own a Nvidia-Card but only ATI-graphic cards as many other people do too and creating a "feature" which can not be used by 50% (or more) of the users (since ATI is often faster for games and is often less expensive people like to buy AMDs) while there is an alternative which can handle both manufacturers, it is just a logical choice for A:M to use something that helps potentially 100% of the users instead of 50%.

 

In general I like standards better which are supporting as many systems as possible. CUDA has advantages (tends to be a little faster) but it just has too many disadvantages in the other direction and OpenGL has other advantages too (for instance you can access CPU-power with the same commands too, which is not possible with CUDA), it is widely useable, etc.

 

See you

*Fuchur*

 

 

Thanks, I didn:t knew that. Thought Cuda would be necessary for all gpu rendering.

 

Wonder why the Octanepeople exclude all the rest?

[Fuchur]

Easy: I dont own a Nvidia-Card but only ATI-graphic cards as many other people do too and creating a "feature" which can not be used by 50% (or more) of the users (since ATI is often faster for games and is often less expensive people like to buy AMDs) while there is an alternative which can handle both manufacturers, it is just a logical choice for A:M to use something that helps potentially 100% of the users instead of 50%.

 

In general I like standards better which are supporting as many systems as possible. CUDA has advantages (tends to be a little faster) but it just has too many disadvantages in the other direction and OpenGL has other advantages too (for instance you can access CPU-power with the same commands too, which is not possible with CUDA), it is widely useable, etc.

 

See you

*Fuchur*

 

 

Thanks, I didn:t knew that. Thought Cuda would be necessary for all gpu rendering.

 

Wonder why the Octanepeople exclude all the rest?

 

I think mostly because CUDA was available before OpenCL-standards were and the Octane programmers were some of the first who used GPU-power for rendering, so they used the technology they had.

Now it is harder for them to rewrite the render-engine, especially since it is explicit written to work with CUDA-commands and not very open for other GPU-command-sets. CUDA may be a little faster too, but I doubt that this is

because CUDA is better but because Nvidia's implentation of OpenCL is just a little slower than ATI's (because they want to push CUDA instead). But this is only guessing... never did a 1:1 test (which is hard, because you cant run CUDA on ATI... so you need

the exact same computer with different graphiccards which need to provide the same performance from ATI and Nvidia, which is close to impossible...

 

Anyway both technologies are (in the right circumstances) much faster than CPU-renderings...

 

See you

*Fuchur*

[jakerupert]

Hi Fuchur,

 

Thank you for clarifing things to me.

 

When I see examples of peoples work with differentp hysical renderers, I also notice huge differences in looks and quality.

Is this due to huge differences between software or could that outstanding quality I see

with Maxwell or Arnold especially in the cartoonlook sector also be achieved with the

other programms?

Maybe its a question of eachs specific materialsystem?

[Fuchur]

Hi Fuchur,

 

Thank you for clarifing things to me.

 

When I see examples of peoples work with differentp hysical renderers, I also notice huge differences in looks and quality.

Is this due to huge differences between software or could that outstanding quality I see

with Maxwell or Arnold especially in the cartoonlook sector also be achieved with the

other programms?

Maybe its a question of eachs specific materialsystem?

 

Maxwell is using bruteforce algorithms. This means they just dont care about rendertimes.

While other renderers tend to simplify things to get faster results and take it that the quality if the rendering may suffer a little maxwell just runs on and on and (in the right circumstances) will provide higher quality and it is the users turn to stopp it somewhere ehen the quality is nice enough. Like that since they r not concerned about rendering time they can use techniques/materials which are not limited in anything.

 

Bruteforce-algorithms are actually nicely scaleable, that means: It is easier than other techniques to cut the rendering in small parts to use with many different threads. So they are highly effected by GPU-rendering speedvise. Still they are slower in normal situations than other stuff... think of it as Radiosity vs Ambietn Occlusion. Radiosity will give you the better looking results but will take much longer than AO. Which style you want is your choice, but it will cost you something if you are using radiosity.

 

The bad thing: you need hours per frame to get great results. And of course some renderengines are just better than others...

That is true for the quality of materials, the style and the rendering itself. And keep in mind: the best renderengine is nothing without a good user who can use it.

 

See u

*Fuchur*

 

Ps: never had a closer look at Arnold so cant say much about it but what i heard is, that it is using bruteforce too and is like that a physical correct renderer.