UPDATE: We’re now going to release the new (and old) items in the Asset Store.
First off, the Scalable Cube.
Did someone here ever use the Hammer Editor of the Source Engine? You can create cubes for walls of floors and such, and every cube updates it’s own uv map (or however they do it) so you can use the same material on different sized cubes.
This is not possible in Unity.
With the Scalable Cube, it is.
Simply create a new one, drop a material on it and resize it. Done. More about it (including live demo).
Second one: The Map Modifier.
Has someone here played Left4Dead? Did you ever want to create a system that modifies a scene in Unity so you could create different gameplay experiences with the same map (scene) like in that game?
The Map Modifier makes it possible to create “Map Mods” which are applied when the scene is loaded, deleting GameObjects that don’t belong to your current modified level design. Read more
The donation idea didn’t work out that well (maybe it’s been a too communistic approach?), so here is a change of plans - the Map Modifier is available at the Asset Store for $10.
Ah, scaleable cube - awesome idea. Really, the idea was in hammer editor that these objects were keeping a real world map size, which was great for rapid prototyping!
The sphere and the pyramid wouldn’t really be worth the effort. That would be lots of calculations which, in most cases, wouldn’t even bring satisfying results.
However, the cylinder would be an idea (though it might cause lots of calculations, too), as well as a plane.
Maybe we’ll find the time to get to it.
Probably - I don’t know about the perfomance though.
The ScalableCube works with UV Map updates so nothing additionally has to be calculated in realtime.
I don’t know about the performance of triplanar shaders, and i dont know how well triplanar shaders work with static lightmaps.
Anyways, you can use any shader you want on the ScalableCube, I don’t know if anyone has a triplanar toon shader ready to go
Update: The ScalableCube now also contains the ScalablePlane. Same concept. I work with material instances instead of mesh instances, but other than that…
Now you can resize your Ground Plane / Inner wall / whatever you use your planes for without having to create lots of materials with the right tiling.
If you already own the package, you can update it via asset store.
And if you don’t: The price stays the same
Triplanar texturing will work with any mesh regardless of UV. The difference is that your UV is calculated using the object’s position in space (local or global space) instead of a predefined UV coordinate set. This is VERY useful for complex, dynamic geometry, for example with marching cubes, where you have no idea what the mesh will look like. If your mesh is changing every frame, it’s definitely more performant to use triplanar shaders instead of calculating the UV manually. The shaders require performance once.
The cost of recalculating the UV manually every frame will scale up with every new object. This can make a major hit with a lot of objects (then you also have to create a manager to not update objects that are outside the camera view… you’re basically reinventing a renderer on the CPU instead of using the GPU).
Unity thankfully takes care of the idiosyncracies of getting triplanar projection shader code to work with its own lighting models, which should include lightmaps (it computes the missing UVs for lightmaps when baking).
For performance, the slight overhead of calculating the UV coordinate at every frame instead of doing a simple (optimized by GPUs nowadays) lookup for a UV coordinate can become significant. Another overhead is the extra calculations that need to be made to simulate tangent space (you can skip this step when you don’t use normal maps). However, you can use a lot less materials (one per tiling texture, literally). This requires a lot fewer draw calls and no further management of ‘shared’ materials, if you trust Unity’s dynamic batching feature.
Beyond calculating the UV, as far as I can tell it’s just standard rendering going on so shouldn’t impact performance. However, for primitives that are ‘only’ scaled once in a while (compared to changing the geometry every frame), it’s best to calculate the UV manually. When that’s done, your mesh is compatible with just about any material you can throw at it.
Oh wow, I was literally searching for something like this yesterday. I was afraid I was going to have to make my own. (The cube, actually, not the plane. I don’t doubt I’ll find the plane useful eventually, too, though.)
I don’t doubt that tiplanar shaders probably have a better performance in realtime.
I didn’t make the ScalableCube with the intention to create dynamicly resizable objects for ingame mechanics, I had the hammer editor of the source engine in mind. I thought Unity just missed the functionality to create simple geometry without external modelling, like it’s possible in source or the unreal engine.
The ScalableCube working at runtime was a not unwanted, but also not intended side effect.
When I use the asset myself, I usually disable the script when the cube has the right size. You can as well remove the script completely.
I don’t exactly recommend using my package at runtime.
Still, I think that my solution is the better way for editing simple geometry in the editor because everything’s done when the game is delivered and you only have the usual 3D model calculations going on. Plus, every shader ever created can be used on this.
By the way, I already bought your triplanar shader pack and I like it!
But there is no toon shader in it
Just wanted to let everyone know that if you have a need for the cube to scale based off of the parent GameObject simple replace all instances of “transform.localscale” with “transform.parent.localscale” in the ScalableCube.js script. I don’t think it works in the editor but works great in game. Of course you could do like I did and expand the script to check for a parent and only use the parent if one exists. Hope this helps someone. Thanks FlaSh.G for a great little script.
I get this error with the Scalable Plane. Is there anything I can do to prevent that?
Instantiating material due to calling renderer.material during edit mode. This will leak materials into the scene. You most likely want to use renderer.sharedMaterial instead.
UnityEngine.Renderer:get_materials()
ScalablePlane:Update() (at Assets/ScalableCube/Scripts/ScalablePlane.js:43)
ScalablePlane:Awake() (at Assets/ScalableCube/Scripts/ScalablePlane.js:31)
I tried a lot to remove these errors, but nothing worked.
There’s some material leaking happening with the asset, but aside from the error messages, that’s not really a problem.
Some explanation: Unlike the Scalable Cube, which updates its own UV Coordinates when resized, the Scalable Plane updates its materials, which is easier to handle.
It also means that errors get thrown. Using sharedMaterial, like proposed in the error message, is not an option here, since that would break other object’s materials.
I guess leaking will at least cause some overhead.
But you can deactivate the ScalablePlane component before building in order to prevent it from recalculating anything.
If you do so, you will have regular cube meshes on the target platform.
