4/8/2023 0 Comments Magicavoxel import into unityYou need to do something to make rigging and physics with animation much, much easier. While the flexibility of Unity is awesome in this regard, most game developers want to drop a character into a scene and have it walk, run, or stand there without too much trouble. (Hey, if anyone from Unity reads this: There's thousands of settings, checkboxes, dropdowns, and variables that you can set in Unity for animation and each one can throw off your animation. You see 10,000 posts about 'root motion', curves, each animation needing it's own avatar, and other spaghetti thrown at the wall of suggestions. You do, but that doesn't fix it, so you do what everyone else does and tinker away into oblivion until whatever good advice you get no longer works and you end up pulling your hair out. Likely, you've had the problem of the animation warping back to where you started and you search the internet only to discover that someone says "check root motion". Then you try to use Mixamo for some great looking animations, but you flail around in desperation as nothing works like you wanted it to. These are the best solutions, but often, the model isn't what you want or need, so you picking something else. So, third party providers try to provide solutions by providing models that are rigged and animated. Your character walks through walls, goes up, sinks down through the floor, etc. You found a great model, you try to use it and you have a mismatch between rigging and animations. So chunks makes sense for these reasons mainly.I'm writing this post because well, Animation in Unity is a nightmare for independent game developers. Plus, if you want a never ending world.you can continue to add 16x16 chunks when you get near the edge of a map but its hard to recreate the one megamesh and just add some area to an edge. The frustrum culling can easily discard any 16x16 chunks behind the camera and off to one side quickly and easily where as one single object would force all the trangles through hte GPU only for them never to be drawn. The fastest technique to render is ALL the cubes in one mesh but then that makes creating and destroying cubes slightly slower. GPU's want many vertices to process all at once.not 100,000 separate draw-calls (of 12 triangles each) AppGameKit would struggle to render 100,000 individual cubes (each as a mesh) at any sort of usable speed but put them all into one mesh and its much much faster. Quote: "Would you say adding more cubes to a single mesh speed things up more or is 16 x 16 somewhat of a sweet spot? Anyway, not trying to hijack this thread."Īdding many cubes to a single mesh makes it massively faster. For each cube it just has its position and color. But a GUI tool where models could be built from small cubes (probably options for the size) would be useful and each object is saved out in a simple format with the model name and list of cubes making it up. I mean sure it can be done but again it isn't efficient. ![]() I found it is too involved to do this stuff purely in code. ![]() It'd be cool to have a very simple voxel modeler that spits out a file that can be very easily loaded into AppGameKit with lists of the cubes making up the models. That being said though I have played around with this idea before of making everything out of tiny cubes (not THIS tiny as they are using) for the same reason. I mean it definitely looks great but aesthetically to me this completely loses the appeal of a voxel game as far as what people think of when they hear "voxel game". Very useful for destructible environments. I mean everything is already made up of hundreds or thousands of tiny cubes so no need to realtime split the geometry and so forth. to me it doesn't even look like a voxel game and seems like the reason they went with voxels was purely technical because this allows the objects to all be destroyed easily.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |