Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[AlecJames]

A new official release is a great idea

Updated documentation is also great news 

 

[thecolclough]

...probably should just bite the bullet and call it v1.0. That way I can start on v1.1 sooner

hooray for relatively-sensible version numbering! 

[Trevor]

Got a suggestion or is it a bug? - Reading on Multi-threading this should already be happening.

Multi-core processing.

When using An8 on my new CPU I notice that only 1 core is ever used.

Ive checked the Multithreaded menu option but no difference

Trev

[danielstritt]

I believe multithreaded means it uses a seperate thread to render than the one it uses for UI, so the UI is still responsive. I believe the renderer is always single threaded

[thecolclough]

I believe multithreaded means it uses a seperate thread to render than the one it uses for UI, so the UI is still responsive. I believe the renderer is always single threaded

yep, that's exactly it.

...so, anybody wanna join my campaign for actual multi-core rendering?  Trevor sounds like he might be interested?  we'll have placards, and t-shirts just as soon as i can get them printed, and hopefully a campaign cake...

[Trevor]

Aww that's a bummer...

Id have thought the renderer would have been multi-threaded. it would still work on a single core 98 box since the OS takes care of threads and which core to run them on.

My idea of multi-threading the renderer would be to divide the render-view into a grid and each grid-square render on a separate thread.
For each grid as soon as 1 pixel gets a colour, fill the square with that colour, repeat for each corner of the square then divide up the square into 4 rendered pixels etc., etc. until the frame is fully rendered (or stopped).
You could set a menu option for the number of grids. (thereby limiting the number of threads to a user amount for large images)
It would be up to the user to choose either (in my case) 16 threads, each logical processor would run at 100%, or use more for a finer grid but incur OS latency in thread switching.

Trev

[davdud101]

I believe multithreaded means it uses a seperate thread to render than the one it uses for UI, so the UI is still responsive. I believe the renderer is always single threaded

Yikes. I did always look at the cores and noticed that only the one is in use. <Multithreaded still does work FAR better than the alternative for me, as Anim8or generally crashes if I click on the UI while not running Multithreaded when rendering.

thecolclough, is it worth it? Although it seems you can't allocate one instance of the software to one core, it's SUPER easy to render an animation using multiple instance and I've never noticed any dragging on the cores/CPUs because (my impression is that) Anim8or can only run as fast as it's programmed to. Maybe I'm misunderstanding the purpose of multithreaded rendering.


Feel free to call BS on everything.. I got far too little sleep last night :]

[thecolclough]

davdud - if you're rendering multiple frames at once, then as you said it's easy enough having multiple instances each doing separate frames.  i did that for a short video clip recently and it worked fine.  if you've got a quad-core, for example, then you can have up to 4 instances going in parallel without them slowing each other down (as you said, again).  but if you're doing one still image, then you can't use multi-instancing for that, so it'd be helpful if the single-frame render process could harness all cores at once because then you get your one image in a fraction of the time.  thinking of ART renders in particular.

a multi-core rendering system is only an advantage if you've got a multi-core CPU, of course, which i realise not everyone does, but most PCs built in the last few years will have at least 2 if not 3 or 4 (and my rig has 6), and that trend is only likely to increase. 

[Trevor]

I also just realised that in my example you would want twice the threads as cores since on a 1:1 relationship, any slow grid will still be processing on its own after all the rest have finished.

If you have more threads available, then any core that finishes first will get to start the next thread thereby reducing the number of idle cores.

The latency in thread switching I was talking about is less significant than idle cores.

Again though, none of this affects single cored Celeron processors, except that perceptually the image will build faster since it will be filled rather than black with a thin red line moving up.

Trev

[ELECTROHERMIT]

I would name your latest build Anim8or 1.0 Version

0.98 in my opinion satisfies all of the objectives you apparently set forth for Anim8or at the start. The program is reasonably stable and more than covers the basics of 3D modeling, rendering and animating for which the program was designed. As a user, I have depended upon Anim8or as my go-to 3D program for creating storyboards and basic concept models. The sheer speed and simplicity is in itself elegant and unique and I believe is unmatched in the world of 3D software. I find myself coming back to Anim8or, time and time again when I need speed and freedom of mind. I would not sell this program short with any further partial version numbering. I would suggest also that awarding this build the title of ONE, will motivate and inspire to take things to the next level.

[davdud101]

And hopefully, that'll assist in getting this community up and moving again! It's been awfully quiet around here lately

[Trevor]

Since this is a development suggestion Ill post here since I feel that posting in the v1 forum should be limited to that build.

Scene mode needs the ability to cop/paste elements.

Its been mentioned before by Kreator here

When is the next dev build going to be ready?

Trev