2D Sprites can be 9 sliced, So why can't 3d models be 27 sliced?

A 9 Sliced 2D sprite allows scaling with some areas of the sprite to remain the same scale. Great for UI and sprites where some parts of them are to be left to their original scale.

So would 27 sliced or 9³ slices be useful for 3D models where we would like some aspects of them to scale and others to stay fixed e.g. A 3D doorway, walls with tops, or blocks with bevels, columns with tops and bottoms could be resized without needing to go back to a 3D modelling tool?

 

What problem are we solving here?

If I slice my pizza into thinner slices, do I get more pizza?

Seriously, I don't get it. I see math to solve problem of, "make the door smaller, but not the windows." That's not a real problem for people, is it?

 

It can be done, I have done it before. It's going to depend heavily on what you actually need to do, and it requires some planning for the art. What I did is build an editor tool to place planes on on the axises. (up to 4 planes per axis, a positive stop and start and a negative stop and start.). And then few more settings to specify mins and maxs. My idea was to functionally clone what Fireworks used to have, dynamic shapes. There was a method runtime/editor called DynamicScale that took the place of LocalScale. It worked well for meshes designed for it, but made a mess of just random meshes. It was also simple in that it just moved verts beyond the planes. So texturing had to be simple. If I were to redo it today, I would add additional mesh loops so I could get more creative with the textures.

Primarily it was built for runtime deformations that were part of gameplay. If it was just for changing the shapes of doorways and such, I would probably just to do in 3d. A generic solution requires setup and preparation both of the model and in editor. Unless you had dozens of variations on a single doorway, there are faster ways to do it.

As @BIGTIMEMASTER pointed out, it doesn't solve a generic problem. At least not well enough to be broadly useful. If it is a specific case, it is easy enough to do. Could probably even do it (at least some of it) in shader.

 

This can be useful. I have done 3 sliced for 3d models for differing lengths/height, but it requires marking which vertices are which slice of a model, it takes a bit of work and is best done on a project-specific basis. Also any texturing can break down if it is not simple or world-based UVs.
Hoping Unity themselves focus more on making core features the best & most robust.

 

Arowx, how many of your ideas are "just add more numbers?" Between this and the 64 bit stuff, the billion core thing... it's a little weird.

This is not even remotely difficult to implement yourself, even with Unity's nightmare of a mesh library. It's also not generic enough to be a meaningful addition.

 

You can easily, no you dont need a modelling tool, and yes it is almost entirely useless except for a very specific set of circumstances.

Thats before you add in the additional overhead on making the assets just to get them to slice, whereas you would probably find it faster to just make the assets you need.

Unless your making some strange thing where almost every 3d model can be scaled in all sorts of ways, then I dont see why you would wanna do this.

What you described is already done in a ton of games anyway using tiled 3d assets:

https://forums.tigsource.com/index.php?topic=54424.msg1233315#msg1233315

That achieves what you describe except it uses tiled assets + marching cubes to compute it. You could break the things down into even smaller pieces to make the transitions less blocky.


I am almost certain you post these type of posts to get a reaction out of people, because I cant really understand any other logic behind them.

 

I've just made a tutorial about one method of doing this:

 

I like the idea behind this approach but can you re-scale a skinned-mesh in Unity then can you switch it to a normal mesh?

As Skinned meshes are expected to be animated and therefore contain an animation rig and having lots of them will reduce your games performance (I'm presuming this in theory it could have minimal a impact unless animations are running).

Ideally you would want a 9 slice models in edit mode and static models in game mode. There may be occasions when you want a 9 slice animation in game for a cartoony interactions.

 

Inverting the parent scale is clever!

Also, this kind of thing actually does seem kinda useful, although other tools probably make it unnecessary, I could see how this kind of thing could come in handy for prototyping, proc gen and the like.

 

The thread has already shown the fundamental starting point of this statement to be untrue. Most people here don't want 9 slice models because they're not really that useful.

Why?

Then just don't animate them in the other situations, or use blend shape based models that extend to 2x past how far you'd expect them to have to grow.

I'm going to classify this as an A, B, and C type Arowx thread:

A type: Arowx has not encountered this problem but feels it could theoretically exist
B type: Arowx has asked why Unity is not implementing a solution to the problem that only theoretically exists
C type: Arowx has asked Unity to implement a feature that could easily be hammered out in less than an hour on the developer end

 

That is crazy expensive.

 

sharing this for people who find this thread through google.

some github links for a 27 slice shader
- https://github.com/specoolar/Unity-Shaders
- https://github.com/hannesdelbeke/unity-27-slice-shader
a unity plugin
- https://forum.unity.com/threads/27-slicer-9-slicing-but-for-3d-meshes.1200301/

 

This is an old thread, but those links are amusing - however I see no textures with those links, if the objects are textured you have to deal with re-UVing the center which would make things rather more complicated. I am not sure doing it with a shader is the answer unless you really need frequent real time changes.

More interesting than 27 slicing is parametric modelling which allows much more.
But there is no particular standard for parametric modelling that I know of and Unity efforts like Archimatix have a few issues.

 

Looks like it's just a standard triplanar shader.

 

Re-uving would require same algorithm as stretching the geometry itself, only with extra calculations. Inferring what "slice" (corners or middle) the current fragment belongs to, from object space coordinates, then applying some sort of correction