3D Max generate objects from animation frames, copy frames to viewport - animation

Is it possible to copy all animation frames into separate objects in the viewport?
I am already using the Path Deformation and the Array tools, but they cannot (as far I know) animate materials. Also, their output cannot be edited with the curve editor??
Example:
I have a 30 frame animation of a rotating box moving along a path. Instead I would like 30 boxes in the viewport. Each one, a copy of its respective keyframe.
Sort of like the classic video technique of creating trails from moving objects. I know it can be done in After Effects, but I want to actual 3d models from my own custom animation frames, in the scene and not the results from Path Deformation and Array. Then I can work on them as a still image.

Select the object and use this maxscript code:
for i = 1 to 30 do at time i snapshot $
It will create a collapsed copy of the mesh at each frame.

Related

How to apply animation to different objects

I have a cupboard with 9 boxes. On one of them I have animation, which open / close box. It is only change X coordinate of the box, but I can't apply this animation to another boxes, because animation will move it to the coordinate of the first box.
In the debug mode parameter Keep Original Position XZ are disabled. Can't understand, what is wrong.
Should I create 9 similar animations for 9 boxes?
I know that it is possible to animate stuffs using relative positions on the UI when using the anchors, but there does not seem to be any clean solution for 3D objects... This post offers what seem to be the "best" solution for now (it uses an empty parent transform to move the animated object correctly...)
You should be able to apply the animation to any object. I would recommend making a prefab of the "box" with the animation attached, then using the prefab for each. Honestly I don't have much experience with animations of 3D objects, but even my 2D animations are in a 3D space, and each object animates properly with the same animations individually regardless of their location.

Thee.js. textures from canvas refers to the lastone

I'm creating some textures for a tiled map.
I have 10 images. I put every one on canvas (to see it), then create a texture from canvas.
I think there is some persitent link to the canvas because the 10 textures created are equal to another (the last one).
Are three.js saving some information relative to the canvas and the 'neeedsUpdate' means that the same canvas is used ? (and if the process is fast I have the same canavas image for every one of 10 ?)
Any idea ? Thanks

Print a 3D object animation in 2D

Here what I need to do is print the 3D animation transitions in my animation clip in 2D format. For example printing a human animation walking on paper. Is there a way to do this?
There are several aspects to consider:
Splitting the animation up into frames
Rendering the frame
Retrieving the rendered frame
Splitting the animation up into frames
Before you render a frame, you have to decide, which frame it should be. Depending on your requirements you may want to render only keyframes (frames that have been defined by the animation artist or the mocap data, but may not be evenly distributed over the duration of the animation), or to render frames that are evenly distributed over the duration of the animation (i.e. render one frame every 0.2 seconds).
Once you know the frame, you can tell the AnimationController to jump to that specific frame and update the 3D model accordingly.
Rendering the frame
Again, depending on your requirements, you may want to consider using a Camera with an orthographic projection. This will remove any perspective distortions, making it easier to visually analyze the animation. If of course the goal is a more visually appealing or "artistic" presentation, a perspective projection may be desired as well.
Retrieving the frame
As you want to print out the rendering, you need to retrieve the result of the rendering. You can do this either by letting Unity take a screenshot (Application.CaptureScreenshot), or by having a RenderTexture and setting this as the render target of your Camera. You can then copy the contents of the RenderTexture to a Texture2D (Texture2D.ReadPixels()) and save that to disk (Texture2D.EncodeToPNG/JPG())

OpenGL ES. Hide layers in 2D?

For example I have 2 layers: background and image. In my case I must show or hide an image on zoom value changed (simply float variable).
The only solution I know is to keep 2 various frame buffers for both background and image and not to draw the image when it is not necessary.
But is it possible to do this in an easier way?
Just don't pass the geometry to glDrawArrays() for the layer you want to hide when the zoom occurs. OpenGL ES completely re-renders everything every frame. You should have a glClear() call at the start of your frame render loop. So, removing something is done by just not sending its triangles. You might need to divide your geometry into separate lists for each layer.

What are the pros and cons of a sprite sheet compared to an image sequence?

I come from a 2D animation background and so when ever I us an animated sequence I prefer to use a sequence of images. To me this makes a lot of sense because you can easily export the image sequence from your compositing/editing software and easily define the aspect.
I am new to game development and am curious about the use of a sprite sheet. What are the advantages and disadvantages. Is file size an issue? - to me it would seem that a bunch of small images would be the same as one massive one. Also, defining each individual area of the sprites seems time cumbersome.
Basically, I dont get why you would use a sprite sheet - please enlighten me.
Thanks
Performance is better for sprite sheets because you have all your data contained in a single texture. Lets say you have 1000 sprites playing the same animation from a sprite sheet. The process for drawing would go something like.
Set the sprite sheet texture.
Adjust UV's to show single frame of animation.
Draw sprite 0
Adjust UV's
Draw sprite 1
.
.
.
Adjust UV's
Draw sprite 998
Adjust UV's
Draw sprite 999
Using a texture sequence could result in a worst case of:
Set the animation texture.
Draw sprite 0
Set the new animation texture.
Draw sprite 1
.
.
.
Set the new animation texture.
Draw sprite 998
Set the new animation texture.
Draw sprite 999
Gah! Before drawing every sprite you would have to set the render state to use a different texture and this is much slower than adjusting a couple of UV's.
Many (most?) graphics cards require power-of-two, square dimensions for images. So for example 128x128, 512x512, etc. Many/most sprites, however, are not such dimensions. You then have two options:
Round the sprite image up to the nearest power-of-two square. A 16x32 sprite becomes twice as large with transparent pixel padding to 32x32. (this is very wasteful)
Pack multiple sprites into one image. Rather than padding with transparency, why not pad with other images? Pack in those images as efficiently as possible! Then just render segments of the image, which is totally valid.
Obviously the second choice is much better, with less wasted space. So if you must pack several sprites into one image, why not pack them all in the form of a sprite sheet?
So to summarize, image files when loaded into the graphics card must be power-of-two and square. However, the program can choose to render an arbitrary rectangle of that texture to the screen; it doesn't have to be power-of-two or square. So, pack the texture with multiple images to make the most efficient use of texture space.
Sprite sheets tend to be smaller
files (since there's only 1 header
for the whole lot.)
Sprite sheets load quicker as there's
just one disk access rather than
several
You can easily view or adjust multiple frames
at once
Less wasted video memory when you
load the whole lot into one surface
(as Ricket has said)
Individual sprites can be delineated by offsets (eg. on an implicit grid - no need to explicitly mark or note each sprite's position)
There isn't a massive benefit for using sprite sheets, but several small ones. But the practice dates back to a time before most people were using proper 2D graphics software to make game graphics so the artist workflow wasn't necessarily the most important thing back then.

Resources