Sorry to bother you again steve, but i have yet again a small request for anim8or. I know this is probably asked before, but i'd like to point it out once again: Copy and pasting object/figures/elements in scene mode.Using cre8or, anim8or can now simulate physics. However it's a hell of a job to create a decent scene for it.Without being able to copy and paste in scene, you will have to manually import all you objects.When I, i.e, want to build a simple brick wall of a couple of feet heigh/width, i will have to import hundreds of objects. Have the option to copy/paste your objects within scene mode will make this job alot easier. So will generating particles or mutliple figures.

I hope you will consider this function in a next release and i hope other animaters will be as pleased with such an addition as I would be.

A small idea that I have is grouping multiple object and/or figures in Scene mode. It would really help with organizing when, for example, you make particles manually and your list is so long you don't really know which one's in which part of the particle effect. I think that grouping them would be better so at least you know which object is with which. I also think that is good to be able to animate them individually while inside a group. Maybe it's just be, but I get quite annoyed if my list gets too long.

Another idea would be about the timeline. Most of the time, when I make a new keyframe in the middle of the sequence, it annoys me to fix the orientation and position of the bone/object (in Scene mode) in the next frames before the following keyframe. It seems that the settings in those empty frames were saved or something. Also when I move a keyframe in Scene mode, there's an extra length between the new position of the frame to the next/previous keyframe (basically where the key was originally placed in the timeline). If the timeline could act somehow like a timeline from a Flash program (recalculating the movements, not saving the movements even on empty frames) so it would be easier to edit the keys on a timeline.

I hope you understand what I'm trying to say. Just reply if you don't and specify which part wasn't clear to you.

I would like to discuss this normal map vs bump map thing as well. Normal maps have a definite advantage over bump maps in that it preserves the directions of the detail in the three different channels. Bump maps only perturbs the surface in the direction of the existing normal whereas normal maps replace the normal entirely in the direction(s) the normal map reads out as.

Bump maps on a single polygon always look flat from an angle, but normal maps account for the proper distortion it should have in any angle making for a much more realistic effect. This is why other 3D programs allow for normal map usage instead of regular grayscale bump maps. The difference is tremendous both in-game and in-cinema, especially when it comes to smaller detail.

I found an image that best shows what I mean (a=bump, b=normal, c=relief):

Notice the details and how from that angle the normal map version is more accurate and realistic than the bump map version. Definitely an upgrade!

Raxx, there are two ways to use normal maps for bump mapping: normal space and tangent space. However both are equivalent to bump mapping as supported in Anim8or. Anim8or converts height images into tangent space normal maps internally to do bump mapping.

It looks like image (b) uses something more like where the texture coordinates are first offset by the bumpmap normal and then that value is used for both the texture color and normal perturbation. Where did you get that image? It might have a better explanation.

i hope this doesn't piss anyone off. but anim8or needs a lot of the stuff blender (blender.org) and other animation programs that cost money have. but the great thing about anim8or is how simple it is.

so basically what i'm saying is if the best parts of blender, anim8or, (and whatever great, free programs i can't think of) were to just come together everyone would be happy.

Steve, I don't honestly completely understand how the bumpmaps are calculated. Basically though, the normal map he's discussing have the R G and B channels. The program would then use these channels, probably for each pixel, and you could use these to calculate x y and z coordinates to calculate the fake normals that would then be rendered.Whereas it seems to me from a bumpmap, even if it were changed into a normal map, could only give so much information, as it only includes black and white, enabling only two axis.

Anim8or creates normal maps exactly like the ones that are shown in these examples as part of what it does internally to draw bumpmaps. They use all 3 channels red, green and blue, to specify the change in the normal. But this alone can shift the center of the bumps as image (b) above does.

I can do what xalener has fairly trivially but I can't do what (b) does without first undertand exactly waht it is doing. It is possiblly using a view-dependent normal map, which is too compute intensive for Anim8or to do.