sprockets The Snowman is coming! Realistic head model by Dan Skelton Vintage character and mo-cap animation by Joe Williamsen Character animation exercise by Steve Shelton an Animated Puppet Parody by Mark R. Largent Sprite Explosion Effect with PRJ included from johnL3D New Radiosity render of 2004 animation with PRJ. Will Sutton's TAR knocks some heads!
sprockets
Recent Posts | Unread Content
Jump to content
Hash, Inc. - Animation:Master

GPU rendering?


Tore

Recommended Posts

  • Replies 20
  • Created
  • Last Reply

Top Posters In This Topic

  • Hash Fellow

Steffen gave OpenCL (the open source version of GPU computing) rendering a big try when he was developing v18 but it did not have the reliability or the increased speed that was hoped for.

Hash had a similar experience when they tried to implement Gelato (Nvidia's original GPU rendering scheme) some 10 years ago.

For now, the idea is on hold until some substantial improvements in the development tools arrive.

Link to comment
Share on other sites

  • Hash Fellow

CUDA is an NVidia proprietary way doing pretty much the same stuff as OpenCL

 

As far as I know it is not different enough to expect the results would be much different.

 

from Wikipedia:

 

Unlike OpenCL, CUDA-enabled GPUs are only available from Nvidia[17]

 

 

OpenCl supports both NVidia and AMD GPUs so that was the choice to try on A:M because A:M needs to support both.

 

 

 

I don't know a lot about this area of computing and my explanations will be very basic and probably inaccurate but that doesn't mean that Steffen overlooked some simple thing that everyone else in the world knows.

 

Steffen really did put a lot of time into implementing it and trying it, but just as the Hash programmers found out with Gelato, the things that A:M does don't seem to benefit much from this sort of GPU computing. It is not going to be a simple matter of using CUDA instead of OpenCL.

 

There is really nothing more that I can explain about it. Steffen would have to weigh in to give more insight.

 

 

Link to comment
Share on other sites

I've had some success modelling and animating in AM and exporting obj sequences to Element 3D which lives within After Effects... E3D is a gpu processor... very swift, great effects like SSS and DOF... works great for motion graphics, not so much for character stuff.

Link to comment
Share on other sites

This is why A:M really should revisit it's export of mesh animations(and exports in general) and test them in various

engines to improve the transfers.

 

It seems as though no real-time solutions are going to be available in A:M anytime soon. BUT I do think the exporter

quality and variety could be improved for faster and more use able mesh animation exports.

 

Just my opinion, but this would patch the gap until real time rendering solutions could be achieved in A:M.

 

Imagine if A:M had a special export to AE specifically streamlined for use in Element. Or a dedicated system to export FBX without having to fight through the current workarounds.

Link to comment
Share on other sites

  • Admin
Imagine

 

Much easier to imagine than implement.

 

A:M really should revisit it's export of mesh animations(and exports in general)

 

Export gets revisited from time to time but exporters are usually plugins. These usually require external development.
Someone with the need usually develops the solution.
An example of this is Arthur Waselec (and others) who have coded exporters.
At one time Arthur offered to assist others with updating his plugins. I'm not sure if the offer still stands or if anyone took him up on the offer.
and test them in various engines to improve the transfers.

 

Testing takes additional time... has to be factored into development.

 

 

It seems as though no real-time solutions are going to be available in A:M anytime soon.

 

It's hard to predict the future. Just when we think we see it clearly... off in some other direction it goes.

 

 

exporter quality and variety could be improved for faster and more use able mesh animation exports.

 

Yes, quality and variety can always be improved.

 

Just my opinion

 

No not just opinion. Thus far I believe you have posted facts and expressed your desires.

 

(improved exporters) would patch the gap until real time rendering solutions could be achieved in A:M.

 

It seems to me that we need experts who work with those other programs to gravitate toward developing plugins for A:M.

It's harder for folks who don't have the need, access, interest, etc. to break through that gap. I'd say it's like someone breaking through a wall that requires 20% effort versus someone on the other side who would require 80% (or simply lacks the manpower or tool). The ideal solution would appear to be that of pairing someone with the knowledge from both sides of the wall and have them communicate and explore optimal solutions to breaking through. Offers have been made in the past but usually interest fades quickly as soon as the idea meets up with real world resistance of almost any magnitude.

 

Imagine if A:M had

 

I spend an inordinate amount of time imagining things that A:M can have. :)

 

if A:M had a special export to AE specifically streamlined for use in Element.

 

 

Or a dedicated system to export FBX without having to fight through the current workarounds.

 

How much would that be worth to us? I'd be more than willing to pay another $20 a year... bumping A:M's annual price back to $99 a year but I can't speak for others. For many/most, $79 a year is too much.

And I recognize that $20 is not enough to fund development of even one of these exporters.

I'm not sure what the solution is. Perhaps we can run a campaign, "Show some love for A:M" and see how many folks will subscribe for a year to send a loud and clear message that we all want to see A:M step up the pace in development and are willing to financially support that effort? Perhaps Jason could make sure the Hash Inc store won't refund additional funds paid at time of purchase and folks could pay more than the minimum amount? Or perhaps a second option to purchase A:M for $99 could be added to the store and folks could choose between the cheaper and more expensive to let Hash Inc know the development interest is for the future.

 

Aside: I had best state why I talk about money here so that my intent doesn't get misconstrued. Moneys primary function in this capacity is to shorten the time of development. Without specific funds to pay a programmer to write code, new lines of code tend to flow at a slower, natural pace. When funds are set aside for specific purposes then those purposes can receive focused time and attention. Money isn't the full solution either however because of stipulations often attached to those funds. Example: I'd pay $200 more for A:M if it had . $200 more of imaginary funding will only buy me $200 more of imaginary development.

 

There are logical steps we can take that meet with reality and yet drive solutions.

One of the simplest steps is to add a Feature request into A:M Reports.

But most of us (I'm talking mainly about me here) don't even get that far in our efforts to develop the future.

 

There is an infinite amount of things that can be done to improve A:M.

Special exporters require special attention and FBX exporters a knowledge of import/export solutions.

-- a slight aside: Most folks desire exporters but fewer see with clarity that we need the full cyclic solution that includes the importer too. Perhaps when we say 'exporter' we actually see that as importer-inclusive. The code to produce each is considerably different so this shouldn't be the case but as end users we don't care about that stuff, we just want the immediate solution. We have several exporters whose created content is one-way only which is sub-optimal. In a perfect world any data that can be exported/saved out of A:M should be able to make the round trip back into A:M also. (But... dangerwillrobinson,.. full solutions tie up developers who cannot go on to explore other code).

 

Some other practical steps we can take (especially in the interim) is to document current approaches and best practices with... I dare say... an A:M-centric approach.

Many non-funded purchase orders start off with 'how can A:M help me use this other program'.

And so the idea generally starts off broke and has to be resorted.

In my day job (actually a night job) I often resort to a saying that generally states, "a great idea that cannot be implemented isn't a very practical solution'.

Something that can help in this regard is to list constraints/obstacles that prove troublesome to those ideas.

It may be that someone has already formulated a workaround or viable solution.

 

Link to comment
Share on other sites

 

E3D is a gpu processor... very swift, great effects like SSS and DOF... works great for motion graphics, not so much for character stuff.

 

What is the drawback for character work?

 

 

Here is an example of how I am using A:M E3D... doing an awards show presentation graphics(yawn) and the award calls for a 'gold crown'... clients had nothing designed. I googled 'crown' and one of the 1st images was an ideal design. Using it as reference, in A:M I modelled it and exported as an obj. Import that into AE/E3D and apply a gold texture and adjust the physical attributes, lighting, AO etc. I am working at 1920 X1080 on a fast PC... not going to say it renders 'real-time' but it renders pretty durn close to real time... I just rendered a :10 test loop, it took :14 to render- and that is WITH all the extra compositing and glitzy layers and filters I added in AE...

 

AS FAR AS CHARACTER stuff... I dunno- I guess I say that mostly because I have not tried it too much yet. There would be the issue of exporting the obj sequence... replacing all textures... I am spoiled by A:M, ever try to adjust lights or camera in AE??? It is a terrible, terrible interface. Maybe I'll give it a try again.

temp2.jpg

Link to comment
Share on other sites

  • 1 month later...
  • 1 year later...
  • 2 months later...

I've just noticed this for the 1st time... There is a GPU column in NetRender. I had opened some Render Messengers using my desktop link for V18 NR and saw the GPU tab was unchecked... when I updated my desktop link to the V19 RM all my Slaves are now GPU...? I don't really see any improved render times... this is new!

 

aaa_3.jpg

Link to comment
Share on other sites

  • Hash Fellow

GPU in Netrender still only applies to things that A:M uses it for like SSAO.

 

I suppose it's possible you might disable it to prevent a bottleneck of several frames trying to do SSAO at once or if there were some inconsistency in results among frames on different computers with different GPUs?

Link to comment
Share on other sites

  • 10 months later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...