rickh

I was considering that. I definitely could do it. Initially it will be seperate plugin and we will see how well the concept works first. The thing is that it will be a useful tool while you are building a new rig for a model and that might mean either leaving it as a seperate plugin, or combining it with the install rig, but add a interface window to the Install Rig plugin. I definitely like the idea of minimizing the number of plugins - too many is just plain confusing. Richard Harrowell.

David and Mark, This is the logic I was considering for my plugin: If an offset has been set on a constraint - even if it is currently a zero offset (ie if the offset numbers show up in bold type) and if the offset is a constant value, I will recalculate the offset. If there is no current offset, I will assume that I should not calculate this offset. I am assuming here that there will be some constraint that are never meant to have offsets. For example, if you want the eyes to aim at a target null, you probably really do want the eyes aiming exactly at the target null. Finally, if a constraint seems to have an animated offset, I will not touch it's offset values. So in practical terms, this would meant that in the Squetch rig, someone would need to identify which constraints need to be set, and see that a value has been entered into the offset properties. In many cases, this will mean typing in offset values of zero. Does that sound reasonably compatible with the Squetch rig? Constraints do not have custom names, so I cannot use naming conventions to control which offsets get calculated. If the method I have proposed is no good, I do have an alternative method which would be a text file listing constraints that need to be calculated. Richard Harrowell.

They are fixing the "Export to Model" from an Action ! That is huge! Thanks Mark and thanks Hash. I will be interested to see what you have done, because I now have to do something similar to the rig we are developing. My target for a test version of a plugin to automatically set all the Constraints offsets is Monday. This would eliminate one of the major difficult "next steps" in installing this rig. I can see the day very soon when a rig skeleton can be installed comfortably in 10 minutes. I will have to try and find someone who can compile the MAC version of te plugin. Weighting, smartskin. face poses - no easy way out there yet. To do really well, that can be 2 days work or more. By the way, Mark, let me know if there are any features you need added to the Install Rig plugin. Noel was kind enough to send me a copy of the source, so I can add features if they are needed. Richard Harrowell.

I am not sure it does anything that will help us, unless you are going to get into very serious programming. To access the nVidia features, you have to use libraries that are currently only in the nVidia SDK (several hundred of mBytes to download). I am not sure nvidia licensing lets you distribute the libraries so I think everyone has to download the rediculous SDK. As a result, most programmers do not use the nVidia enhancements. Richard Harrowell.

Same here. Perhaps a plugin needs to be installed? There was something that had to be done from memory. Do you have a file IlmImf.dll in the plugins folder? If you do, then you have OpenEXR support in XNView. Have you gone to Tools->Options->Associations and ticked "OpenEXR" (if you use "view as name" mode or "exr" if you use "view as extension" mode? Richard Harrowell.

OpenEXR is much better from the purposes of film/animation then Tiff. Forgetting the huge compatibility problems of Tiff, Tiff cannot handle multiple layers and it cannot handle 16 bit floats (which is all you need for animation or movies). Tiffs have things like 32 bit floating point channels and 64 bit integer, but so what ? - nothing around can seriously make use of that resolution. You just end up storing twice or four times as much data, but no extra content. All of the OpenEXR compresison formats are lossless or close enough to lossless so it doesn't matter - -again this is perfect for renders or post production intermediates. I think it is very lucky there is at least one good image type. OpenEXR is a format crafted to precisely fit the needs of movie and animation work so why would you want to look to other formats, particularly closed source proprietry formats (lie all the alternatives are). Richard Harrowell.

Fusion can actually read multilayer OpenEXR? That is very useful to know. Definitely, very few programs even attempt to read multilayer OpenEXR's at the moment. Richard Harrowell.

If you convert with XNView, the alpha channel is preserved. Probably too many old 8 bit graphics apps. The trouble is that all the graphics plugins were written for 8 bit and it will take time for everything to be replaced with floating point versions. So with TGA's, you can put renders straight into Virtualdub and you have temporal filters, blur, crop - you name it. Same with lots of the favourite photohop plugins that people have collected over the years. Even if I was going to use 8 bit programs, I would still render in OpenEXR and then convert the renders in XNView. Sorry to MAC users if I keep mentioning all this Windows software, but you are luck enough to have Cinepaint available - OpenEXR support, layers, full set of floating point image tools, frame buffer, scripting, cloning between different frames, etc. Its going to take ages for the Windows version of Cinepaint to become useable. Richard Harrowell.

Increasing numbers of programs support OpenEXR nowadays, and at the high end level, most can support it. The problem is that when multiple layers are used in OpenEXR, there is no standard for how the multiple channels are defined and so most programs that support OpenEXR will read the top layer and ignore everything else. A:M outputs 16 bit channels, but it is important to make it clear that these are 16 bit floating point numbers which means 10 bits of actual colour resolution per channel, one sign bit, and 5 bit for the exponent. That probably really is sufficient for most purposes - especially if the target is for DVD format with its 8 bit resolution per channel. I would always render out to OpenEXR now instead of TGA's because with OpenEXR it takes the same time, but you definitely get more out of the rendering time. If I need TGA's, then I can always get A:M to convert them, or use the free XNView package to batch convert them to any other 8 bit format in an instant. XNview is like Irfanview that many people may know, but it has the extra benefit of supporting OpenEXR that is something Irfanview cannot do. There is of course only one file manager in the world - TotalCommander, and since it supports XNView integration, coping with OpenEXR images is a breeze. I do think a simple batch utility that can extract layers from an A:M OpenEXR light buffer render to seperate OpenEXR images would be very useful, and when I finish some plug-in programming, I will give it a go. One of the beauties of OpenEXR is that everyone using the format is using the same OpenEXR source code or libraries, so that the compatibility of the format between different applications that support it is absolutely excellent. Everyone usually supports every one of the compression formats. Typically, OpenEXR support by older 8-bit only graphics applications never works to well, but the newer packages that do support floating point colors channels or at least 16 bit integer channels usually support single layer OpenEXR very well. Most of the "compatibility" issues I have seen with OpenEXR relvolve around 8 bit graphics apps that choose to convert from 10 bit floats to 8 bit integer in very odd ways - perhaps they are trying to compress the fulldynamic range of the OPENEXR images down into 8 bit intger range which results in washed out looking images. Edit in floating point and the problems are solved. Every one of the OpenEXR compression formats is completely lossless for A:M renders - even the lossy option in OpenEXR is lossless for the A:M resolutions. This means you cannot really go wrong with the format. Also OpenEXR make fabulous decals for A:M to use, especially for displacement and bump maps. If you are getting A:M to generate decals for A:M to use, then OpenEXR is the only way to go. It is not just the extra 2 bits of real resolution, it is the fact that A:M actually does properly support the floating point displacements so you can get displacements much bigger then 1.0 (equivalent of 255 in an TGA channel). It really is a superb format for movies and animation. It doesn't have the compatibility problems of, say, the Tiff format. The Tiff format does have almost every capability you can imaging (except for multiple layers), but how many programs can actually understand all of these capabilities? The negatives of using OpenEXR really revolve around the older generation of 8 bit graphics programs and low end 8 bit video programs that do not support it, and that is only a short term problem. It is an open format, and most of the alternatives are actually not open formats. The proprietry formats often have licensing issues, limited flexability and since everyone is writing their own different libraries, there are real compatibility problems. I think OpenEXR is an inspired choice of format by Hash and I think within a couple of years, I think the choice will prove to be absolutely correct. Richard Harrowell.

I didn't see your previous post when I sent my last reply, so I didn't know that you have tried V14. A render to disk from the A:M interface in V14 can use dual core rendering. Your photo puzzles me a bit - I would expect both cores to be camped on 100% almost continuously. The snapshot shows you are in the middle of rendering patches so A:M would be asking for maximum power and neither core is near 100% ! . If this is Vista running on an AMD dual core PC, then obviously some application, service or the operating system is robbing A:M of full CPU cycles. If this is the Hyperthreaded Pentium 4 we are seeing, the the display is showing the Pentium 4 is running at full speed. Core 1 + Core2 = 105% which is about the absolute maximum a Hyperthreaded Pentium 4 could do. By the way, if you have XP on one of your systems, why would you want change it to Vista? XP will be more stable for years at least. There is nothing in Vista that can help A:M run any faster then it can in XP. I would definitely try this test out on the AMD dual core with the Xp on it. To see the CPU usage graphs, just run Task Manager. It would not surprise me if the AMD 4200 rendered at about 4 times the speed of the Pentium 4. Also remember that 14 Alpha means Alpha. V14 probably still has a lot of refinement before it is ready for the production release. That probably includes work on the dual core support. Richard Harrowell.

The dual cores are currently only used for rendering - the A:M interface itself still just runs on a single core. Hopefully as work into V14 continues, we might see more multi-threaded code appearing in A:M. There is also a setting on the Global tab of the options window in A:M that sets the number of threads that you want to use. If "Threads" are set to 1 and Auto is off, then A:M V14 will only use one core at all times. By the way, there is nothing "pseudo" about the current multi-core processors - they physically have two CPU cores and if both are running, the speed does double. The old Pentium 4 processors with Hyperthreading - now that was a genuine pseudo-dual core processor. Richard Harrowell.

That diplacement map looked a bit odd. The high points stay high and the low points stay low. Are you animating the right parameter when you make the displacement map? You should start off with a Sine turbulance and then you animate the Z Translate parameter only of the turbulence. Also make sure your amplitude for the turbulence is not over 100% - just under is best. Over 100% and you will start to get some flat spots on the peaks and troughs. It might be a result of the FLv compression, but the movie does seem to have flat regions where the colour is 0,0,0 suggesting you are using over 100% amplitude. Richard Harrowell.

You used to need a dense mesh for displacement maps, but the new pixel displacement maps in the current V13 and V14 no longer needs a dense mesh for displacement. Richard Harrowell.

Correct, the first tut only is for the waves, but the third tut (if you could call it that) is about combining the waves with a wake created by an object http://www.babbagepatch.com/wakes.htm Charlie I never thought of using particles to generate displacement maps - I will have to experiment with that. I did post a method to make a wake using a "moving" displacement map decal ages ago. All the links should still work. [topic=http://www.hash.com/forums/index.php?showtopic=6154]http://www.hash.com/forums/index.php?showtopic=6154[/topic] [topic=http://www.hash.com/forums/index.php?showtopic=4035]http://www.hash.com/forums/index.php?showtopic=4035[/topic] [topic=http://www.hash.com/forums/index.php?showtopic=7012]http://www.hash.com/forums/index.php?showtopic=7012[/topic] It is limited in that I only know how to make decal's "move" in straight lines. By the way, if you are generating displacement maps from A:M, OpenEXR format give you more detail then TGA's, Mov's etc. Richard Harrowell.