Jump to content
Hash, Inc. Forums

Recommended Posts

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.

Share this post


Link to post
Share on other sites

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.

 

 

Share this post


Link to post
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.

Share this post


Link to post
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?

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites
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.

 

Share this post


Link to post
Share on other sites

Well said Rodney. All great points.

 

I completely agree and understand the limitations of developing "new" features.

Money and time are obstacles.

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

what about cycles renderer. it is open source for a while now...maybe an implementation via the sdk is possible? or as standalone renderer with export plugins?

Share this post


Link to post
Share on other sites

What about simply baking the lighting, textures and shadows on still objects in scenes then let AM be able to export that out as a seqence? This would be more like how a game engine would work and the calculations could be done one or at key frames or nth frames.

Doable?

Share this post


Link to post
Share on other sites

You can bake most textures. You can't bake lighting and shadows.

 

But lighting and shadows is what the other renderer is for, right?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

It was HA:MR if I am not wrong.

But it was using OpenGL/Direct3d (as realtime in A:M itself).

 

Best regards

*Fuchur*

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×