Anim8or Community

Please login or register.

Login with username, password and session length
Advanced search  


An update to Anim8or, v1.00b, is available with a few bug fixes. Get your copy HERE. See the "ReadMe" file for details.

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Trevor

Pages: [1] 2 3 ... 13
Oh wow, the re-write also seems to have fixed "bright internal corners" bug.

This is what it looked like before (1332)

this is 1345

Thanks steve,

All triangles have a "front" and "back" face. Most environments cull back faces to improve rendering time, you need to stop that from happening with the "volumetric Sprite" (and Im not sure how you are not clear about what I mean when you attach an image of exactly what Im talking about :S )

Also, there is no post, its an image which is already attached in my post above.


Wow, that thread is exactly the method I used for my lightsaber - though independently thought up despite that thread existing before I created my lightsaber (2010)

Layers of spheres would have heavy banding on top of heavy poly usage.

"volumetric Sprites" - that lightsaber - is the way to go (ok, volumetric sprites might actually mean something else, but this is what I meant by it)


Agreed, You don't want a sphere here, you want sprites.

You can also do it via "volumetric" sprites (see lightsaber)


Its not HUGLY important, but does come in usefull from time to time when modeling inside a box.
At present I use the double-sided material with back set to 0 for transparency BUT if 2 such surfaces overlap then both become transparent (even if facing front) so it doesn't work all the time.

Culling backfaces directly with a toggle switch would be more convenient and should not incur such a bug as the material method.


sorry steve, I don't mean the left hand toolbar, I mean in "Options > [ ]Backside" and "View > Preferences > [ ]Backside"

Disabling these makes no difference in the viewport.


steve, can you fix the "Backfaces" button/preference so that it actually culls backfaces. As far as I know its never worked but it would be handy if it did :)


you can use CAD view (looks like a ruler) and debug A

Oh wow, CAD view has been updated to show legnths of selected lines and angles between them. (whoops, apparently this has been true since Dec 2017)

As for grid, just set it in grid settings.

Ohh… I see, yeah ok, it rounds back to 0.06 instead of 4dp.


Ongoing Anim8or Development / Re: Multi-Threaded Rendering
« on: July 23, 2018, 10: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.


Ongoing Anim8or Development / Re: Multi-Threaded Rendering
« on: July 20, 2018, 05: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.


Ongoing Anim8or Development / Re: Multi-Threaded Rendering
« on: July 19, 2018, 05: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)


Ongoing Anim8or Development / Re: Multi-Threaded Rendering
« on: July 16, 2018, 05:39:25 pm »
I have 2 physical cores and 4 logical cores = 4 threads. I suspect that you have 4 physical cores and 8 logical cores - that's what Intel calls a "8 core cpu".

Erm... no... I have 8 cores, 16 threads, Im not mistaken :P

Hmm, looking at the cores, it would seem that they are all doing something since right before pressing render they were all more-or-less idle, however only 8 red lines ever show up on the preview.

maybe Im missing something?

Ok, so doing some tests with affinity and priority it seems you made a comment earlier that less cores could be faster, it seems your right, limiting to the first thread of each core actually works out faster than allowing all threads to run.


Ongoing Anim8or Development / Re: Multi-Threaded Rendering
« on: July 16, 2018, 12:15:23 am »
so, on your dual core, how many threads do you run? 2 or 4? (Since hyperthreading makes windows think you have 4 logical cores)
I have 8 cores, 16 logical cores and not all cores light up, only 8 do at a time. (obviously some cores also run other processes like windows, but they are not full)


As I stated before, for a touch interface, the addition of a zoom would be usefull, but yes, with a mouse the original arc rotate is far better hence why I said the new one should still accept right and middle clicks (since they cant be done on touch it wouldn't affect them - well, right can, its touch-and-hold-then-drag :P)


Ongoing Anim8or Development / Re: Multi-Threaded Rendering
« on: July 15, 2018, 11:41:19 am »
HOLY CRAP!!! Multi-Threaded rendering has arrived, testing NOW :)


rendered a test (Diffuse Inter-Reflection test as shown on another topic)

83 secs down to 14 !!!! WOW

Also, anyone using DIR should disable fastAA as its actually slower since it always has to do "full evaluation".

My only suggestion now would be to "build" an image interlaced, i.e., blocks of solid -> blocky(coarse) -> final image(fine)

Also, my tests show that ChunkSize 32 is the best for speed, anything bigger gets held up on one or more chunks (like the mirror ball).
32 on the other hand is small enough that each chunk can finish in a timely manner and if its still needing to render then another thread can "take over" since its not tied to a thread.

Can you up the thread count to 16 too? Im only using 70% CPU (anyone have anything more?)

Pages: [1] 2 3 ... 13