Anim8or Community

Please login or register.

Login with username, password and session length
Advanced search  

News:

Ian Ross has just released a book on Anim8or. It's perect for a beginner and a good reference for experienced users. It contains detailed chapters on every aspect, with many examples. Get your own copy here: "Anim8or Tutorial Book"

Pages: 1 2 [3]

Author Topic: Multi-Threaded Rendering  (Read 78578 times)

ENSONIQ5

  • Hero Member
  • *****
  • Posts: 1012
    • View Profile
    • Mission Backup Earth
Re: Multi-Threaded Rendering
« Reply #30 on: July 17, 2018, 03:48:22 am »

This is a game changer!  Rendering speeds are fantastic, attached took about 2 minutes with AA at 100 on i7 quad core (8 threads), image size 1920x1080.  No problems to report at this stage, testing animation at the moment.
Logged

ENSONIQ5

  • Hero Member
  • *****
  • Posts: 1012
    • View Profile
    • Mission Backup Earth
Re: Multi-Threaded Rendering
« Reply #31 on: July 18, 2018, 09:41:49 am »

I've done some more testing and run some render time comparisons between Anim8or V1.0, Anim8or build 1329 with multi-threading, and Carrara.  It's tricky to run a fair comparison with Carrara since it is an entirely different package with a different set of parameters but I have attempted to match the AA, materials and lighting as close as possible on a quick still life with lots of lights (14), ART attributes and soft shadows.  Materials and lights in Carrara have been set to match Anim8or as closely as possible, and the model is identical.  Renders are attached and times are below:

Anim8or V1.0 AA100: 50m 11s
Anim8or V1.0 AA100 (fast AA): 11m 10s
Anim8or build 1329 AA100 multi-threading on: 5m 47s
Carrara: 9m 5s

There are some minor issues with the 1329 multi-thread render (some previously noted):

  • Graininess in the lower-right of the glass ball
  • Apparent lack of AA on objects visible behind the glass ball - some jaggy edges (may be the same issue as above)
  • Slight step in shadow at near corner of wooden ramp, though it is actually more pronounced on both V1.0 renders

Aside from this, the handling of shadows in general and the quality of the lighting is significantly better in 1329 than V1.0 and, remarkably, rendered quicker than Carrara.  This isn't a 'Carrara vs Anim8or' thread by any means as both have their advantages (Carrara for its massively powerful materials engine, Anim8or for it's workflow and simple UV editor), this comparison is only about rendering times.
Logged

Steve

  • Administrator
  • Hero Member
  • *****
  • Posts: 2125
    • View Profile
Re: Multi-Threaded Rendering
« Reply #32 on: July 18, 2018, 02:23:53 pm »

ENSONIQ5: Nice comparisons. I'm really pleased at how well the latest Anim8or compares to Carrara. Carrara's lighting and glass effects are noticeably better, but overall Anim8or's speed and soft shadows seem to match Carrara's.
Logged

ENSONIQ5

  • Hero Member
  • *****
  • Posts: 1012
    • View Profile
    • Mission Backup Earth
Re: Multi-Threaded Rendering
« Reply #33 on: July 19, 2018, 08:49:09 am »

Agreed, they compare very well indeed and the speed is really impressive.  If anything I think the Anim8or 1329 render has the edge, there is a richer saturation and it's a more pleasing render overall.
Logged

Trevor

  • Full Member
  • ***
  • Posts: 220
  • Goldfinger64 Dev OS:10 CPU:5960x Gfx:RX480
    • View Profile
    • LS Tech Services
Re: Multi-Threaded Rendering
« Reply #34 on: July 19, 2018, 01:18:15 pm »

Those Christmas lights just scream "Corona required" :P

hmm, actually, just having a think about it, how hard would it be to have 2d sprites attached to the Z-Near and locked to the on-screen position of "target" nodes?

Bit more of a "Game Engine" feature than a "3D Modeler" feature, but it would be great for renderings (scanline or ART)

Trev
Logged

ENSONIQ5

  • Hero Member
  • *****
  • Posts: 1012
    • View Profile
    • Mission Backup Earth
Re: Multi-Threaded Rendering
« Reply #35 on: July 20, 2018, 03:35:48 am »

Trevor: Definitely possible, I'm planning an animation test with multi-threading and will include coronas :)
Logged

Trevor

  • Full Member
  • ***
  • Posts: 220
  • Goldfinger64 Dev OS:10 CPU:5960x Gfx:RX480
    • View Profile
    • LS Tech Services
Re: Multi-Threaded Rendering
« Reply #36 on: July 20, 2018, 01:41:18 pm »

oh, haha, I know we can do it manually, I was meaning more a An8 feature for Steve :P, it would certainly make ART unique.

haha, I couldn't resist testing my old lightsaber in the new ART

10:33 for full self illumination (DIR) with 64AA - there are no "Lights" in the scene

Final image has corona as close to Z-Near as possible.

Trev
Logged

AlecJames

  • Full Member
  • ***
  • Posts: 240
    • View Profile
Re: Multi-Threaded Rendering
« Reply #37 on: July 20, 2018, 03:40:40 pm »

Trevor - what does it mean "has corona as close to Z-Near as possible"?
Logged

Steve

  • Administrator
  • Hero Member
  • *****
  • Posts: 2125
    • View Profile
Re: Multi-Threaded Rendering
« Reply #38 on: July 22, 2018, 10:01:50 pm »

Trevor: I just posted build 1330 with max-threads of 16. Give it a try!

AlecJames: Backgrounds of all kinds (Panorama, Image and Cube Map) should work for all camera views in all renderers in build 1330.

selden: the int Attribute MaxThreads sets the maximum number of threads. So if you have a 4 code CPU you can set it to 3 to leave a core for you to use while it's rendering. Alternately, you can set it to -1 to use all but one thread, or -2, etc.

Raxx: the main difference with the multi-threaded Fast AA for your scene is the way Anim8or handles soft shadows.

Previously Anim8or would sample sqrt(n) samples for n sample anti aliasing and see what the max color difference was between the samples. If it was too large, Anima8or would take another sqrt(n) samples. Then if the color still wasn't converging fast enough it would sample the full number.

Now the color difference isn't used because highly varying textures could cause a slowdown. Instead Anim8or uses a mask of what lights are visible for each sample. If it is different for the first sqrt(n) samples, then Anim8or samples all the rest. This works very well for normal shadow edges and soft shadow edges that aren't "too soft", i.e. the number of pixels that are partially shadowed is small. You scene has several soft shadowed lights that are very close to the objects which means a lot of pixels are softly lit. So Anim8or sample all samples for them. Since you are using 100 sample FastAA this adds a lot of time.

I have a more sophisticated algorithm that I want to try for later builds that should make much smoother soft shadows with fewer samples. It involves filtering the light separately from the surface material. I don't know when I'll have it ready so keep you fingers crossed!
Logged

Trevor

  • Full Member
  • ***
  • Posts: 220
  • Goldfinger64 Dev OS:10 CPU:5960x Gfx:RX480
    • View Profile
    • LS Tech Services
Re: Multi-Threaded Rendering
« Reply #39 on: July 23, 2018, 06:48:42 am »

Thanks Steve, here are the results

Interior DIR test down from 165 to 100 secs (Chunk 32, AA 64) [Original 1,300s]
Exterior DIR Test down from 14 to 8 secs (Chunk 32, AA 64) [Original 86s]

Lightsaber DIR down from 10:33 to 6:30 (Chunk 32, AA 64)

These speeds are phenomenal :)

Just to test chunksize again I tested interior at 128 and it took 130s (with 30s spent waiting on 1 chunk to finish) and also 64 which took 106, so yeah, smaller chunks are very much better since it spreads the complexity across all cores evenly right to the end.
I tried 16 but it defaults to 100 leaving the lone chunk to finish.

Trev
« Last Edit: July 23, 2018, 07:05:26 pm by Trevor »
Logged

Steve

  • Administrator
  • Hero Member
  • *****
  • Posts: 2125
    • View Profile
Re: Multi-Threaded Rendering
« Reply #40 on: July 23, 2018, 06:08:10 pm »

Trevor: Thanks for the results. As to why ChunkSize=16 doesn't work, Anim8or doesn't use values less than 32 because the overhead of the extra work required increases rapidly below that point. I suppose I should clamp the size to 32 for smaller values instead of using the default.
Logged

KamDrerty

  • Guest
Multi Threaded Rendering
« Reply #41 on: August 04, 2019, 09:42:09 am »

You cant just multiply like that. That chip would probably not be ideal for a desktop because most applications are not multi-threaded well enough to use all that power.
Where it would be good is on, say, a production server that is compiling things with gcc. gcc is very well multi-threaded and would take advantage of the power very well.
Logged
Pages: 1 2 [3]