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.

If you have After Effects 7.0, then the best format to use by a big margin is OpenEXR. This is especially true if you intend to layer your renders by doing some renders with an Alpha Channel. Essentially if you use OpenEXR, you can manipulate the image in AE with effectly no loss in quality for the final video output. If you render in TGA, AVI , etc , any image modification in AE will lose a bit of quality in the final render. Using TGA's is still OK, but OpenEXR is just much better. AE7 can only read single layer OpenEXR so it is no use rendering with the Light Buffers set to "ON". Richard Harrowell.

I agree with Paul about the centre of gravity of the robots as they walked. That really struck me watching the walk video. I love the quality of the modelling and I think you really could be on a winner here. Inspirational stuff. Richard Harrowell.

It basically works for any situation where: 1. No bone moves when a model first opens in an Action (ie - you wan all offsets set so that all bones are aleady in exactly the position the constraints intend them to be in), and 2. You are not animating the offsets. Once I have the plugin working, there are probably refinements I can do, but for the moment I am designing it for models that fit these requirements. And yes, it would be kind of handy for a rig with cogs. Richard Harrowell.

Status of the AutoOffset plugin In spite of the silence, I am making real progress. I have managed to get a working dialog box, and I have worked out how to navigate the SDK to locate the constraints. Work has been frustratingly slow since this is my first A:M plugin, but now that I am finally talking with A:M via the SDK, things are starting to work. This image of the plugin dialog gives an idea of what am trying to achieve: An alpha version of the plugin for PC's is not far away. I do not have the ability to compile Mac versions. Richard Harrowell.

That is very frustrating. Is it simply a matter of getting the Z rotation in the exported model that same as in the action, or does this problem cause errors all the way down the bone tree? Why I ask is that in a week or two, I can probably look at a simple plugin that will capture the bone rotations in the action to an external text file, and then use that to correct the bone rotations in the exported model. Would that work? The thing is that even if this big is fixed, it may only be fixed in V14, and will not be fixed in V12. A plugin can be made to work for all versions. I have the source code for the InstallRig plugin, so perhaps I can add this functionality to it somehow. I think this work is too important to have it stall. It would even be possible to write plugin that would take all the bones and positions in an action and write them directly into a destination model (the one with all the final constraints, etc), but it sounds a bit beyond my plugin writing ability at the moment. Richard Harrowell.

The Auto Offset Concept for Constraints In most rigs for any purpose, you do not want any bones to move when the rig is first dropped in a Choreography or Action. This means that there is no need for manual setting of any Constraint Offsets. All that is needed is for something to set an automatic offset in an action window that compensates for the bone's positions in the modelling window. In other words, it automatically sets a fixed offset for each constraint that ensures no bone will be moved from it modelled position due to a constraint unless you start animating bone positions. Since this is exactly what how you want a constraint to work 99.9% of the time and since it is so easy for A:M to calculate these values exactly for a massive rig in a fraction of a second, it is an obvious feature to have. Noel's refinement of the idea is that the Compensate mode button along with the Offset properties would remain. The offset properties would act as an additional effect to the auto-compensate - it would allow you to deliberately nudge a bone a bit. The Auto-Offset function would actually completely ignore the numbers in the Offset property when it calculates the offset. So you end up with two offsets that get added together. The Compensate Mode button would still generate offsets based on the bone positon in an action rather then the modelled positions, so it is still there when you need to set the offset for a constraint to a target bone that has been moved from its modelled position. In summary, if constraints had this Auto-Offset tick box available, it would mean that in most cases, A:M could pre-calculate all the offsets live and it would cease to be an issue you even have to think about much. In my idea for a test plugin, I intend to use the simple logic that if a constraint currently has an Offset property, then I will assume it will need the Offset recalculated. Any constraint that does not have any Offset property currently set will be ignored. I might have a second option that will calculate offsets for every constraint. Richard Harrowell.

This is exciting. I cannot believe that Mark took on something as complicated as the Squetch rig for his first attempt at this - it is a pretty incredible feat. Now about the auto-offset idea that Mark referred to - basically it is possible with a new feature to totally eliminate the need for any Compensate Mode offsets - either in the rig design or the rig installation process. You would never have to touch that Compensate Mode button again! I am working on writing a plugin to do this, but it is a bit slow since I have to learn how to use the SDK. I think this should be a built in feature in A:M and if anyone else agrees, please add it as a feature request in Reports. Hash need to know if animators want this feature or not. Richard Harrowell.

Do you mean tht when you change the position of something in frame 03:00, the change is applied right back to frame 00:00 ? If that is the case, all it is is you do not have Animate Mode selected. That button with a big "A" on it (top toolbar) needs to be toggled on. Animate Mode can be toggled off so that, say, you can adjust the position of lights in frame 03:00 (which might be the critical frame of your animation) and the llight's position will apply for the whole scene. Normally if you try moving lights on frame 03:00, you just end up with lights that move. Richard Harrowell.

The Intel Core Duo 6700 is a brilliant processor, so I would definitely recomment it. A:M is a single process program so it doesn't make use of the two cores, but you have all that extra processing power available for rendering in the background, running Photoshop as well, etc. Get the X1900XTX if you want but it is more then A:M needs. Any modern midrange nVidia or ATI Radeon graphics card is fine. What you have to remember about these monsters like the dual X1900XTX is that they consume lots of power and require a lot of cooling. A $200 - $300 nVidia or ATI graphics card is still easly fast enough for A:M and will probably run cooler and quieter. A quiet PC is definitely appreciated when someone has to sit next to it for many hours a day. A:M only uses the graphics card acceleration to speed up the realtime wireframe and shaded rendering to the screen in the editing process. No feature of the graphics card is used in the final renders. As a result, you will get the same performance and quality in the rendering of the final movies with a dual SLI X1900 or a cheap $50 graphics card. A higher priority is to spend money on Ram (1 to 2GBytes of fast high quality RAM) and a really good screen (like a high resolution 21" LCD). Insist on Windows XP Pro operating system. Don't touch XP Home because it has crippled networking and if your son gets really interested in Animation, he will eventually need networking. Getting a dual X1900XTX sounds like you are building a super game PC and you might find it hard to keep a gaming PC "clean" enough to run A:M reliably. Richard Harrowell.

Nice catch, Richard! I missed that...thanks for isolating the problem and the detailed description, very helpful. So, there will be another update. If anyone has found anything else, let me know. ---------------------------- EDIT ---------------------------- I think it's actually the "WFingersXCalc_left"....right? David, You are too quick for me! I tried to quickly correct that typo, but you beat me to it. Richard

I have been trying to use the V13 MirrorWeight rig. There is a problem in the hands because it looks like the hands do not have bone symmetry left to right. The end resullt is that if you use the mirrorweight rig, your left hand fingers will bend in the wrong direction when you move the CFingers_left control bone. It would seem that in the rig for the hands, some bones in the left hand were re-orientated so that expressions used to control the finger position could be identical in both the left and right hands. Perhaps it would be better to have symmetrical bones and different expressions left to right? Here are the details. These are the rotations of the bones that drive the finger positions: -> WFingersXBase_right 0, -0.01, -90 --> WFingersXCalc_right 0,0,90 -> WFingersYBase_right -89.98, 0, -180 --> WFingersYCalc_right -89.98, 0, -180 In the non-mirrorweight version of the Squetch rig: -> WFingersXBase_left 0, 0, -90 --> WFingersXCalc_left 0, -179.84, 90 -> WFingersYBase_left -90, 0, 180 --> WFingersYCalc_left -90.01, 0, -180 In the Mirrorweight version of the Squetch rig after mirroring the bones right to left: WFingersXBase_left 0, 0, 90 WFingersXCalc_left 0, 0, -90 WFingersYBase_left -89.98, 0, 180 WFingersYCalc_left -89.98, 0, 180 The major problem is caused by the fact that in the left hand, the non-mirrorweight rig has the WFingersXCalc_left bone pointing to the rear. In the mirrorweight rig, the WFingersYCalc_left bone points to the front. This means that when the CFingers_left control bone is rotated, the Z rotation of the WFingersXCalc_left bone is completely opposite in the two rigs. For the moment, I will manually reposition the Left bones in the mirrorweight version of the rig, but I think better solution is required. This is the first time I have joined the Squetch rig discussion, so thanks David for this incredible effort. The features of the rig are quite amazing. Richard Harrowell.