sprockets Learn to keyframe animate chains of bones. Gerald's 2024 Advent Calendar! 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
sprockets
Recent Posts | Unread Content
Jump to content
Hash, Inc. - Animation:Master

Recommended Posts

Posted

Actually, a GPU has a lot of cores (up to a few thousands) but they are very different and one GPU core is a lot less powerful than a CPU core itself.

For istancen in general a GPU core is not able to use the same instruction sets as CPU cores and like that it is not possible to do it "just like that".

If GPU rendering would be included, it would need a own rendering procedure which takes such things in account.

 

Best regards

*Fuchur*

  • ____ 1
  • Hash Fellow
Posted

I'll note that Steffen did make a run at implementing GPU computing with A:M but it turned out to be not faster.

 

Aside from the coding change that Fuchur discussed, a GPU renderer has to be able to hold all the data for what it is rendering in the GPU RAM so you'd probably need about a 4GB GPU card to do typical A:M stuff.

 

A 4GB GPU card isn't wildly expensive anymore, I'm seeing prices of around $200-$500, but it would be an extra expense you'd have to accommodate.

However, since we don't have GPU computing, you could take that same $200-$500 and get a 4 or more core computer to add to your rendering pile.

 

I don't know much about the networking details but we have people on this forum who could help you with that if you went that route.

  • ____ 1
  • Hash Fellow
Posted

It is impressive that it works at all since the GPU cards were never meant to do number crunching like CPUs do. :lol:

Posted

a GPU renderer has to be able to hold all the data for what it is rendering in the GPU RAM

Not necessarily. It's faster that way but it isn't a hard requirement with modern shading languages.

  • Hash Fellow
Posted

Well, I got taken!

 

My Nvidia board has just 1GB and cost $85 about four years ago. :rolleyes:

  • ____ 1
  • Hash Fellow
Posted

 

How long are your renders taking?

 

It depends, of course, but in average 3-5 minutes for a 1280x640 9xmultipass frame without hair/particles.

 

 

 

You should get in a time machine and go tell 1987 me that the day would come when it would not take 5-15 hours per 320x240 frame with no hair or particles even if you wanted them.

  • *A:M User*
Posted

 

 

How long are your renders taking?

 

It depends, of course, but in average 3-5 minutes for a 1280x640 9xmultipass frame without hair/particles.

 

 

 

You should get in a time machine and go tell 1987 me that the day would come when it would not take 5-15 hours per 320x240 frame with no hair or particles even if you wanted them.

 

 

 

True, I remember trying to do single-frame Povray renders on my 286 and them taking all night since I didn't have a math coprocessor.

 

That said, if you could do those renders faster, why not? It would be terribly useful to be able to do a final quality render in near real-time.

  • Hash Fellow
Posted

I'll tell you why the render time isn't a big hindrance for me personally...

 

The amount of time I spend modeling, rigging, texturing and animating is so much larger than the render time that even if the render time were instantaneous it wouldn't change the duration of the project much.

 

The things that A:M does without me, like rendering, have gotten to be the least worrisome part of it. :wub:

The stuff where A:M is waiting for me to do something is the big bottle neck that no render speed up will change. :(

  • Admin
Posted

Tore,

I'm always suspicious of comparisons because they are taken in isolation.

 

While it is a goal... and they are well on their well on their way to it... EEVEE rendering in Blender currently does not support animation other than that created by rendering still frames via camera and object translation, rotation and such.

 

That's why the scene from the video you showed, while impressive only shows a static scene where nothing moves in any way that would be called 'animation'.

 

This isn't to downplay Blender's progress.

They are definitely moving in the right direction but from a holistic view taking all things into consideration... especially fully articulated characters.. it's not a particularly useful comparison.

There are tricks that can be used to limit rendering time in A:M that can get similar response and we should definitely pursue those.

Ed Catmull once said, "Computer Science is the science of dirty tricks." and this is still largely true.

We just need to find innovative ways to leverage those tricks.

 

 

For other shortfalls and hints of 'dirty tricks' that can be smoothed out and optimized see the EEVEE FAQ:

 

https://code.blender.org/2018/03/eevee-f-a-q/

 

Added: It's interesting to note that initially in the FAQ it is stated that EEVEE supports animation but then later specifically states otherwise.

Posted

in the FAQ it is stated that EEVEE supports animation but then later specifically states otherwise.

It isn't supported in the sense that the animation engine hasn't been ported over from the 2.7* branch yet. The renderer itself doesn't care what exactly happened to the polygons that are being thrown at it.

  • Hash Fellow
Posted
...EEVEE rendering in Blender currently does not support animation other than that created by rendering still frames via camera and object translation, rotation and such.

 

 

 

What does this mean? Does this mean 2D motion graphics like you do in After Effects with flat images but no 3D objects?

  • Hash Fellow
Posted

You question is not stupid. I don't want to belittle you for it.

 

But you have asked it... it's going to get an answer.

 

What I can tell you is what I know about A:M's development and how i know the lack of GPU rendering isn't because it's not been tried and how I see rendering time in the whole production process and what i know about other solutions to rendering time that can be done now.

 


My next suggestion is a very serious one. It is not meant to brush you off...

 

Blender has the render features it has only because they recruited very knowledgeable people to donate a huge amount of their programming time and knowledge to make it happen. Those are not trivial additions.

 

Recruit a similar team to do that for A:M. That is what it will take. It will take an enormous programming effort. I don't see anyway to make it happen except to find the people who can do it.

I mean that very seriously.
















  • ____ 1
  • Admin
Posted
If that idea is stupid

 

 

Why must ideas have such characteristics?

Ideas are not inherently smart... stupid...

 

As for the quote "An idea is a seed not a solution"...

 

I wouldn't have written it if I didn't believe it.

Ideas are like seeds in that they must be nurtured so they can grow, blossom and bloom.

But they also must weather the storms and be firmly planted in order to do so.

 

There is a common thread that is hard to pin down in A:M circles where people seem to take offense very easily. (It's not unique to A:M clrcles BTW!)

The only rationale I can find for it is that as artists we are conditioned toward this response.

But we want feedback... we want ideas... we want speculation... the more the better.

And it is precisely because we have a reasonable expectation that our desires may not be met that we can march forward boldly into the future.

 

We'll get there.

  • ____ 1
  • *A:M User*
Posted

I'll tell you why the render time isn't a big hindrance for me personally...

 

The amount of time I spend modeling, rigging, texturing and animating is so much larger than the render time that even if the render time were instantaneous it wouldn't change the duration of the project much.

 

The things that A:M does without me, like rendering, have gotten to be the least worrisome part of it. :wub:

 

The stuff where A:M is waiting for me to do something is the big bottle neck that no render speed up will change. :(

 

 

This is true, I am also the limiting factor in terms of getting things done more so than rendering. I don't know that having extremely fast final renders would make much difference in that regard. However, where they might make a difference is in all the iterative test renderings that we often do when testing lighting, materials, etc. on a scene. Now 5-10 seconds as opposed to 5 minutes for a test frame would be a valuable thing. We can work around this somewhat by doing lower resolution tests or rendering only a portion of the screen but sometimes you need a full frame test at final quality.

 

Blender and AM are very different in the way in which they are developed. Blender is a community effort with dozens if not hundreds of programmers. This is not true of AM.

 

I am happy enough with AM, I am not investing more time at this point in my life in learning a completely different software. I suppose if I had to at some point and was forced to adopt Blender I would but I'd much rather work with AM.

Posted

Interesting discussion.

 

I have had opportunity to delve into GPU rendering of late using a little software plug-in that works within Adobe After Effects called Element3D from Andrew Kramer of Video CoPilot. From time to time I share my findings here on the forum. E3D is lightning bolt fast, and excels at uber-high resolution 3D work. The company I am with does video presentation for conventions and shows which typically have projected screen resolutions of 8,000 pixels wide(=/-) by 1080pixels high and to render animation frames out of any 3D CPU renderer would be prohibitive...

 

E3D has a limited feature set... it is not a modeler at all- tho it can extrude AE live type with nice bevels. It has animation features that rival to a degree Cinema4D's mograph feature... so you can duplicate and warp your creations in nifty arrays. It does allow importation of obj and obj sequences which is cool because that bridges it to A:M nicely, and offers a sort of an 'alternate renderer' to A:M and because it is a GPU renderer.... fast! Things it can-NOT do are many... your hair and A:M particle effects are right out... reflections are 'faked' which is a big negative in my book- but it sort of fakes them nicely. SSS is faked, tho nicely... refraction is faked via phoney offset, and even shadows are not as easily controlled as in A:M because they have to work in conjunction with AE's lights- which are half-baked and clunky. Ambient Occlusion has 2 varieties (SSAO or raytraced) but with a great deal of flexibility and speed for both so that is a PLUS.

 

Here is a test I did recently with an A:M render that I put some time into making nice. I like A:M's DOF, and the floor reflection falloff in A:M and fog feature is an easy favorite of mine. Other programs just don't 'get' reflection falloff as illustrated here. They want to confuse it with 'Fresnel' effect which does not get you this look- which I like. Also fog... you would think it is such and easy comprehensive feature... similar to depth mapping... but they can't get it like A:M does. Look at the fog falloff in the E3D render- sort of 'all-or-nothing' whereas the A:M fog is gradual. Nice. The rim in A:M was a high density obj prop, I simply applied my material 'Chromanence' to it... I could not export it via obj so I used another rim in E3D and hand-tracked it to the motion. ALL the materials in the E3D render are drag-n-drop PBR materials... the type was an afterthought added in AE and matted there. The volumetric light was added using Trapcode Lux which is a nifty AE filter that makes AE lights volumetric...

 

Final note: I did not make note of exact render times... the A:M render was 864 X 486 and took minutes per frame and went overnight. The E3D render was 1280 X 720 and took 2-4 seconds per frame while I waited and the 6 second clip was finished within 2 minutes.

tire render comparison.mp4

Posted

Talking renderer's... I remember buying a $50 3D program called Impulse Imagine before I tried A:M... way back in the mid-1990's. I did a modeling tutorial (a torus!) and then wanted to see it rendered so I put it in the render module under the camera... nothing- black frame. Every time. I shelved it in frustration. I did not know what I was doing wrong until I tried A:M and did a similar test with my 1st A:M model and saw in the chor that a basic lighting setup was already provided as default... it hit me- I had never added lights to that scene! I was rendering pure darkness! What a newb!

 

Today's renderers sort of take it to the next level, they start you right off with a nice Image Based Lighting setup, easily modifiable... a robust library of PBR materials are drag-n-droppable and with very little effort- you are making great renders. Want to add a light? Easy. There is a lot less of the 'you got a lot to learn, kid' mentality and more of the 'look at that amazing image you made' thinking, which is far more inviting.

Posted

AM used to have a real time renderer, I forget the name but I believe it was intended for games? Wonder if it's possible to dust off that old code and update it to modern standards?

  • ____ 1
Posted

There was 1st a 3rd party thing called Arctic Pigs which generated a lot of hubbubb and was fully functional back about V10-11 days and then the entire A:M code was rewritten and since there was big gaming interest Martin hired a special programmer to take-over the endeavor named Ken Chaffin and the project was renamed HA:MR for Hash Animation:Master Realtime. With time, interest fizzled and as Hash lost marketshare and programmers the effort was shelved. The quality of the realtime was not much more than what you get in-program... it just added interactivity in a web environment.

  • Admin
Posted

Yes, to the best of my recollection no shaders (as we've come to know them) were in the HAMR pipeline.

Basically, if you could see it in a realtime preview inside A:M you could see it in HAMR enabled viewers (web browser or standalone application).

  • 2 weeks later...
  • Hash Fellow
Posted

Well, now Blender actually has realized the concept and from the latest nightly builds and forward, rendering can be done with either CPU alone, GPU alone, or both in tandem. I tried out the speeds with this test render:

 

CPU (2 CORES) alone: 11:46

 

GPU / CUDA alone: 8:56

 

GPU + CPU (2 CORES) together: 6:04

 

 

 

I am very surprised to find out that that is all the difference there is between CPU and GPU rendering.

 

I thought it was nearly real time. I thought it was supposed to be like just seconds to render a frame.

 

 

If that is all the improvement there is, I'd say, no, it's not worth putting more programmer hours into after so much effort has already been put into it with no useful result.

 

 

If 11 minutes is the problem and 6 minutes is the solution I would do the thing I already know I can do today, that already works today... get a box with some cores in it.

 

 

 

  • Hash Fellow
Posted

I would have thought the difference would be far greater than a 2X speed up.

 

 

Is that Bela Lugosi? :D

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...