Here are links to the v14.0 Alpha Installer.


Windows:

• v14.0 Installer (2006 - Yeti CD ) (11m)
  
• v14.0 Network Installer (Hasp Requires 2006 subscription) (15mb) ]

OSX (Universal Binary):

• TigerInstall14.zip (23m)

Features:

• Toonnation "Terrain" plug-in included (from Andy Wittock)
• "Noise Reduction" Post Effect
• Tint Post Effect has a "Rainbow" style that helps create ChromaDepth 3-D style stereo renderings. ChromoDepth 3-D is a registered trademark of American Paper Optics.
• Flash export (.swf) included (from Marcel Brickman)
• .obj import/export included (from Arthur Walasek)
• .DXF export included (from Arthur Walasek)
• [0003419] FPS is about 10x slower in bones mode (Mac and PC) - tysono_71
• gamma corrected Preview render
• % distributed raytrace shadows
• specular component included in photon maps
• "Consolidate" has a "zip" option
• HA:MR export
• MIDI control included (from Steffen Gross)
• "Mirror Bones" included (from Steffen Gross)
• "Pharr" shader.
  
  Windows Only
• [0002675] render support for multiprocessor/multithreading/dual core machines - JohnArtbox
• [0003750] Multi-threaded Rendering - rickh

Make sure when you report bugs to A:M Reports, and that you pick the v14 project in the upper right.

There's a gamma setting in the render options for starters.

You guys just dropped down a bombshell! I knew you guys were hard at work at something. I'll have to check this out.



BTW Gamma was in V13 as well
I see what you mean now.

Oh, and Will, you have v13.0 Alpha written down instead of v14.0 Alpha
Fixed it

-----


I see something new. Distribute Passes feature in Lights with Raytraced shadows.

How to use:

1) Use the spinning gamma chart to set the current gamma setting for your monitor. Move a distance away from your monitor until you cannot distinguish the lines in the left side of the gamma chart. Scroll up or down until the two sides of the gamma chart look the same gray level.

2) Enter the desired gamma correction in the edit box above the gamma chart. That would normally be 2.2.

Now this gamma correction will be applied to any progressive or quick renders. This will allow you to adjust textures and lighting for a given gamma correction while doing render previews.


If this is checked, then the number of ray cast for raytraced soft shadows will be distributed among passes. There are two benefits to this:

1) If you set a given number of ray cast for a given soft shadow quality, then you don't need to adjust that number if you render with multipasses with different number of passes.

2) If you set the number of ray cast to, let's say 2, just to get soft shadows, then each passes will cast only one ray instead of two each. Thus reducing rendering time by approximately a factor of 2.

Did some testing with Distribute in Passes; here are the results.

[attachmentid=21043]

[attachmentid=21044]

There is an decrease in rendering time (roughly 20% in my test); however, like with most time cuts comes some sacrifice of quality. Distribute in Passes creates a more splottchy shadow.

For the test, ray casts were not changed (2 rays). Multi-pass was set to 16 passes with soften.



-----

Is the Normal Map maker not included in these? It seems like it should come standard with A:M.


-----

Where did all of the reflectivity options go?
I see them now. When you add a reflectivity value, the options appear. Much neater.

Oh yeah!

I'm almost afraid to try some of these options for fear I might have to use them.

Lookout A:M Community I'm about to start plugging the upgrade to v14 so get ready for it.
Its easy to see that v14 is already a 'must upgrade'. You should start saving your pennies now.

It depends on the scene complexity. For very simple scenes, the gain will not be very large. As you start adding more lights in the scene and more objects, the difference will spread apart.

16 ray cast for soft shadows is not much anywway. If you find that 2 rays per passes with 16 passes gives you a good soft shadod, then the number of distributed rays should be set to 32 or something. Then, of course, you will not gain any render time. Distribute ray cast does not do magic in regard to soft shadow quality. You will still need the proper number of rays. However, you only need to set the number of rays once no mater the number of passes you select,

This distribute rays will really start to show its usefullness when used with large light rigs for instance.

Also, you may want to test the Noise Reduction post effect plugin to try to get rid of shadows noise.

Hmmm... Still can't set Ambiance above 100%.

I reported a bug, but when I selected Product Version, there was nothing to select.


-----

Did one last test with Distribute in Passes. This time it was just a render of shadows.

[attachmentid=21045]

numbers above are in seconds.

50.28% is much faster.

You mean I can upgrade to a duel core Intel Processor now?



Someone's going to have to explain that one. I didn't see that anywhere in radiosity.

-----

I don't see the Noise Reduction Post effect. Are you sure you loaded it?



Yves, won't we still have to use Gamma corrections when using radiosity to decrease the amount of contrast in our renders?

Is this good for n processors or a max of two?

Just wondering what should start wishing I had instead of my single CPU machine

Any predictions on the efficiency? I'm guessing that 100% use if multiple CPUs is impossible.

Way to go Hash!
Render support for multiprocessor/multithreading/dual core machines. I am taking it that this will apply to net render? Please say it is so!

It is not a radiosity option. It is just that the final gathering pass takes the specular intensity and size into account when sampling the scene.

I'll have to check. It should be there.

This Gamma correction is only for preview renders. It is not applied to final render. You should normally apply it to final render too. But only as a post processing step. And Gamma correction should be done only as the very last post processing step if you have a whole serie of post process or compositing to do.

Not yet, but is on the list.

I have trouble in bones mode click on model to get default bone no bone appears and AM closes

I think it is capped at 32 until we see some 64 core machines... There is a setting in the tools->option panel to set or limit the # of processors.

Will multiprocessor support be available for MacOS before the 14.0 release version?

sorry, can´t find any noise reduction in the post effects. maybe its not in the installer.

Wow!!!
The new features and enhancements sound amazing!

Bravo, Team Hash!!!

ok, i did some renderings to test the multithreading support and now i am very confused.
i did the test on a P4 hyperthreading,3Ghz, 1Gb RAM, ATi Radeon 9800. a simple ambient occlusion scene with a ground a sphere, no lights, AO 30%, 16pass, resolution PAL.

now the results:

with "threads: 1" settings in the global options: 6min 14sec
with "threads: 2" settings in the global options: 9min 42sec
with "auto" settings in the global options: 9min 30sec


why is the rendering with only 1 thread faster then the one with 2 or auto? when i do a rendering with the preview progressive renderer, i can actually see the two processors rendering. i am doing something wrong, or does the a:m-multithreading not support Pentium4-hyperthreading in final rendering mode?

oh, and is it possible to have a line in the status or options bar where it says how many threads a:m currently uses(when rendering to file)?

Just a thought here, Willi...

Are you sure that you have enabled multithreading on your machine?

Just a thought.

yes, multithreading is enabled. i can see it in the task manager. also when i render with the progressive renderer. confusing are the render times.

here is the sample project.

If you only have 1 processor, and you have threads set to "2," everything will be slower - not faster. It's best to have number of threads equal to the number of processors otherwise the multitasking overhead is for nothing.

Hi Willi,

This isn't really an answer, but some more info, Hyperthreading from Intel means you've really got one single CPU and the OS (Win XP) is treating it like two.

I've got a Hyperthreading P4 myself, and awhile ago tried to run some tests with two instances of A:M running vs. one. If I remember correctly, running one instance of A:M didn't really mean WinXP was only using 50% of the CPU (like the Taskbar seemed to show). In actuality it was more than that.

So hypothetically, if you're running A:M v14 with one thread enabled, let's say you might be running near 90% of your CPU. Now if you run with two threads, where is that other thread going to run? You don't really have dual core or two CPUs. It's just your one CPU again.

-Jim

Willi

If I have understand the hyperthreading concept from intel right , you cannot expect that a rendering with two
threads is faster than with one .
Why not ?
When a thread creates near 100% cpuload (each render thread would do this), is nothing cpuload left for a secondary thread . Now the scheduler (he shows two cpu's, but they are only logical cpu's) distributes the avaible cputime time to 2 threads , wich creates everytime at a contextswitch a overhead . (the cpu must save and restore her state, and some other things (cacheline etc) + time for syncronizing the threads) and this produces as effect a higher rendertime .

For machine with two real cpu's , like Core2 or X2 , this doesn't happened, because each cpu get one thread .
Offcourse you cannot expect , that this is 100% faster than working with only one cpu. You have also a overhead (synchronize the threads) , but this overhead is much, much lesser than with hyperthreading .

As example for the toys project I got with (finalrender, AMD X2)
1 Thread 2:04
auto (or 2 Threads) 1:08

cool infos. the confusion is gone. have to test v13 rendering times with v14 rendering times.

Ill defiantly be doing some render testing with V14 this weekend. We have been working on some renders that were taking 5+ hours for 1 frame. This is a AMAZING enhancement! Way to go hash. Especially since the new Intel QUAD core chips will be out by the end of the year.

Some information i have learned about the quad core and more is that Windows XP will work with the quad core but if you plan to go DUAL Quad core (motherboard with 2 quad core processors) you may have to wait for windows Vista. Although Windows Server 2003 will support Dual Quad Core, Windows XP will only support 1 quad core chip.

This is good news for mac boot camp users though. Now I can throw my Mac Mini into the render farm and get more performance out of it.

Thanks Hash!

OH MY GOD!!!!
You guys are great!

again confused. don´t know if this is a good reference test...

here are some screenshots of my test-project.


threads settings "auto". the progressive renderer is using 2 threads. my cpu is 100%



threads settings "auto". the final renderer is slow. my cpu is at 50%. the same with Threads at 1.


the scene took in v13 the same time (6min14sec) as in v14 with 1 thread.
my conclusion is that if you have a hyperthreaded cpu you don´t have any rendering time decrease at all.

it´s a pity. need to upgrade to dual core cpus!

Willi,

I don't think you do have hyperthreading activated on your test computer. The reason I think this is so is because your performance pannel shows only one "CPU usage history". This is what I get on my non-hyperthreaded computer. But on my hyperthreaded activated computer, I have two "CPU usage history" windows side by side. Look in the "View" menu of the "task manager" and see if you have the option to "Show one graph per CPU" in the "CPU History" sub-menu.

i used another cpu diagnastic tool. "active cpu". my windows taskmanager is showing two histories of the cpu. i wanted to know if another cpu tool is also showing the same %-usage of the cpu as the task manager. "active cpu" seems to show the physical cpus in his hisory panel, in my case 1 cpu.

btw, what about the missing "noise reduction" post effect?

Yves said he was going to look into it. Until then, Neat Image is still an option.

Isn't hyperthreading just one CPU acting as two CPUs? The only reason I could think of that hyperthreading with two threads would be slower is because of the cache process. 50% added to the render time with two threads seems over the top though.

Duel core will work right? I have this one in mind. Would it speed things up a bit on rendering times? (Just not the 64 Bit Part)

I've been doing multiprocessor code since 1985: the dirty secret of multiple processors is that "they suck." Programs are written as von Neumann machines... which don't usually work in a multiprocess, non-von Neumann environment. Empirical investigations show that after 4 processors, most applications get no improvement in performance. Luckily for us, computer graphics, especially raytracing, is one of the few applications that get good efficiency out of multiprocessors.

Multitasking/multithreading is not the same thing as multiprocessors. Multitasking/multithreading get almost no efficiency improvements except by utilizing support processors, like i/o or GPU. The overhead of switching tasks on a single CPU is enormous because the cache and CPU pipeline have to be dumped so often. It the old days when RAM was at a premium, it was 10 times worse.

I haven't tried this alpha yet, but...I hope zipping is an option and not enforced - my main uses for consolidate don't usually result in an immediate zipping. For example, I use it to make clean copies of projects to take a new direction with the project, to clear out unused files, to copy to other users on the same machine (for background rendering), etc... Even if I consolidate to pass projects to other people, I generally try it out first before zipping.

OK. I checked for that noise reduction plugin and it is my bad. I didn't include the folder in my SVN commit. I just did that now but the pugin will only be available in the next alpha release. Sorry.

No harm no foul, still lots of time to play with new features.

Is anyone able to render normal maps in quick render? Mine just seem to render some strange curvature in quick render but are visible in a final render.

[attachmentid=21063]

The large streeks over the geometry is most likely the normal maps messing up in quick render.

v14 wouldnt load for me
came up with a MFC71.DLL error

Updated the ChromoDepth part of the initial post to include a link to the rough tutorial.

I was blown away to see the dual-core feature, so I wanted to try it out right away. You guys are programming machines over there!!! I cannot wait to start my own animation studio using only AM. Ahem at any rate back to this quicky benchmark. I know this is still a very early alpha, but i'm a little baffled at the results.

Test System is a AMD 4200 X2

Toy.prj DV Res No multipass or motion blur.

Average 87% Usage of both cores
V14ALPHA DV Res
1:16 Single Thread
1:26 Dual Thread
1:20 Auto

Average 50% (or one core)
V12
:38

I do have a few programs running the background. But something doesn't seem quite right.

-Ethan

Multiprocessor support I hear? FAINTS

But not available for the Mac version yet? GET'S UP AGAIN

Something I have always been wanting… Even more so now that I have a DuoCore Mac - please make it work, please, please…

FALLS OVER EXASPERATED

Ethan
I think this is a problem on your side .
I got very different results (much faster) with the same scene, same settings and also a X2 4200+

2 threads (program affinity not set) 00:26 screenshot
1 thread (program affinity not set) 00:46 screenshot
1 thread (program affinity set to cpu1) 00:49 screenshot

Is there going to be a 64-bit version of A:M v14?

Also, does the .obj import/export keep the texturing now?

Bizarre! Perhaps the background programs are affecting it more then I thought. I will try another test.

Thanks for letting me know,

-Ethan

Congrats to the Hash team for what must have been alot of hard work! I'm already thinking of ordering some of those 3D glasses to see what this ChromaDepth is like.

As for the speed, with this first release I'm seeing some slowdown when compared to v13 using a simple test project. My machine uses a Hyperthreaded P4, so I'm not using multithreading, I've just set v14 to 1 thread for this comparison test. I'm sure if there's something up here it will be figured out.


-Jim

We checked it out, and our render times have also increased since we tested multiprocessors last month. Right now we're blaming Yves, and shuffling through his last week's "commits," but we won't know for a couple hours. However, Ethan's times are much worse than what we're seeing. When we get this fixed, "Toys" is almost twice as fast as V13 with 2 processors.

here at our department, we have a mix of intel machines and amd machines. we realized since v8.5 that the amd machines render much faster than the intel ones. same seems to happen with intel dual cores and amd dual cores. so there must be a amd-optimized code in a:m, isn´t it?

AMDs have two math coprocessors in their pipeline (Intel only 1). A:M is heavily math dependent. We do nothing special.

My next machine is AMD then.

AMD's are the only thing we buy now.

We only have 2 intel systems here, one is Dell notebook, and the other a desktop/slave.

Even our old (1 1/2 years old) AMD Athlon XP's are faster at rendering than the 3.4ghz Pentium.

Yes, zipping is an option. There are actually 4 options, consolidate as prj text file, consolidate as prj text file and zip it, consoidate as prjb binary file, and consolidate as prjb binary file and zip it.

Ken Chaffin- Hash, Inc.