3D sprite file - is this possible, and is it fast?

Recently I decided to pick up an old project of mine which was about voxelizing (cube kind) a 3d object in realtime. To get a feel for what I was going for, this is a short video I made of it:

In short this was too resource heavy and now, years later, I had the thought of pre-rendering the voxelized model either saving the animations as a custom file or as a set of pre-rendered objects which I can add as assets to a final project.

Now I was thinking of taking the oldschool approach of sprites in a 3d setting. So where many of the old games had a single file containing all of the images, I was thinking of doing the same in 3d. So I create a large object which stacks the animation frames into separate objects.

Where sprite animations would display only part of the image per animation frame, I would like to display part of the object per animation frame. This way I can generate the whole of the animation set at once and I only need to shift the part of it I want to view x times per second.

Can this be done and would it be most resource effective way of doing this?

 

converting your model into voxels seemed to be the most expensive from what you said, correct ?, but there are developers on this site who have been dieing to re-create the look you just made

Sprite-style animation, but with 3D assets
so it's pretty cool

what you seem to want to do is

1) use render_texture and bake out a sprite sheet from a custom array of 16*8 camera views (less depending on how much freedom the view needs)
or
2) bake out the animation into an array of meshes and just loop through them

I don't really have answers, just commenting that your project is very cool

 

First of all I like this I don't know how you do it but maybe it could be optimized to consume less resources.
Anyway what you describe with precalculated animation meshes is a known process. It is often used in cases where many, 10.000+ animated objects are displayed.
So yea, try it. Maybe you have to reduce framerate for your animation because this reduces the amount of data.

This method is described here under Baked Meshes.

Also, do you really need this kind of animation? What about static geometry like Minecraft? It still looks similar without that flickering and you could move parts like arms, armoury and so.

 

How this version works:
I put an invisible copy of the goblin/orc with the same animation inside an invisible cube. On 3 of the faces (x,y,z) I put a 32x32 grid of squares. Then I cast a line from the center of each square to the other side of the cube taking the color from the surface on every mesh intersect. Every odd intersect is considered an entry point and every even an exit point. Doing this 32x32x3 times results in a set of 0 to 3 colors for each 3d voxel position. In case of 3 colors I take the average color of the intersection and store that as the voxel color, otherwise it is assumed there is no voxel there.

I want up the resolution to 64x64x64 which means 4x the linecasts and 8x the actual resolution. I want to reduce the color scheme, probably to only 16 values per voxel (that mostly being color).

@McDev02: I saw this in the VGHS series and I was amazed by the animation style.
This inspired me to start this project:

Look for the parts where those voxel critters start attacking each other.

Thanks for the links. Seeing 10000 animated aliens moving smoothly has convinced me that the sprites thing can be done.

Ps. Thinking of limiting the project to a tech demo of a voxelized model performing some animations by pushing the corresponding buttons. I don't mind sharing the code afterwards.

 

Thanks for the explanation. Sounds more like a makeshift approach. I know it is not easy to do, but you would want an algorithm which only works in the script and reads the mesh data in and produces a nice shape with only the vissible faces. If you want to make that seriously then maybe you want to look into that, there are maybe even some libraries available which deal with volumetric rasterization.

I just found a Unity example on GitHub. maybe you can look into it. From a quick look it seems that the script checks each voxel inside the bounds of hte mesh and checks for intersection for each triangle of the mesh.
But then it also draws cubes and does not generate one mesh. But to do that you could look into how Minecraft generates the terrain, it is the same algorithm!

Edit: And it also misses color as you did, you would have to include that into the Hit algorithm maybe and do some texture sampling there and store the colors and then average.
So for hires models your approach might even be faster

 

Really like the way that guy handled the voxelizing, but due to the lack of colorizing I think I have to pass on that script.
Unfortunately I lost my original script, so I'm rewriting it at the moment. Ran into some trouble due to the animated mesh lacking a meshcollider, but re-generating one on each freeze-frame seems to do the trick.

But to get back to the original question. For rendering, putting separate meshes into a single object and showing/hiding those would be the most resource effective way of doing it I presume?

 

If you talk about animaiton and each frame is a seperate mesh then the answere is yes. Or at least it is not a bad idea. Not sure if there is any magic out there that would do it better.

 

Thanks for all of the information. I have a good base to work on now.
When I'm ready to do the loading, I'll just load the voxel-data from file, generate the meshes from them and store them in an array. A custom animator should then be able to replace the actual object mesh up to as many times as the FPS requires.

One more question:
I'd like to create a project forum topic for this as I might be able to get some feedback as I'm building this and to keep anyone who's interested up to date on this project. Is there any spot in this forum I could create a topic for that? I don't want to clutter this forum.

 

yes: works in progress section

https://forum.unity.com/forums/works-in-progress.34/