How should prim cuts work on sculpties?

Given how well the community here worked together to come up with a preferred solution to https://jira.secondlife.com/browse/VWR-9384 I thought this would be a good place for fleshing out a feature request for sculpties.

I've been mentioning that having prim cuts on sculpties would be good for animating them but that relies on a particular way of handling the edges of the cuts. Basically treating them the same as the current edges.

This isn't the best option for all uses cuts could have so I think the wrapping type could be used to decide which type of cut to use as follows:

No wrap: Use partial sculpt map
Wrap: Use segment cut (to open the wrap edge)
End Cap: Use slice cut

So a slice cuts along the Z axis with the caps drawn to a common center (Z from mapwidth/2 and X=0, Y = 0). The end caps should be separate texturing faces from the main sculptie.

A segment cut would remove the wrap face and replace it with faces from each edge to the common center. These faces should also be separate texturing faces.

This gives the benefits of advanced cuts to the shapes where they make sense and leaves the plane type and cylinder type as options for animated sculpties.

So that's a summary of my thoughts, anyone want to help flesh it out, make corrections, figure out what's best for a torus?

i'd like to see this happen!!

I would like to see that I am not being force to use a newer version and continue to use

Component/s: Building (in-world)
Affects Version/s: 1.18.4 Release Candidate
Fix Version/s: 1.19.1.4



Sculptie LOD causes object to be deformed into a flattened sphere close while correct far
Created: 31/Oct/07 01:02 AM Updated: 05/Jun/08 04:54 PM Return to search

So is this a comment against any new features? It's unrealistic to expect new features to be backported to all prior versions of viewers. Sooner or later "must have" new features will only be in the latest viewer with or without any effort on our part in shaping those features.

https://jira.secondlife.com/browse/VWR-9384 is a prime example in that for many of us, the introduction of oblong sculpties in the RC client was the first we knew about it. There was a mad rush from the community to improve the feature before the client goes live. I prefer to avoid going through that again

The end and profile cuts are the only prim editing features that could affect how sculpties are made (specifically how the sculptie map UV is handled), so it makes sense to tackle this now before everyone rewrites their sculptie tools to support oblongs. Even if the feature isn't introduced for some time, it will avoid another tool rewrite as we can allow for it if we have how it should work documented.

Hi, Domino; Can you elaborate in a bit more detail ?

This is my current understanding of your thoughts:


no wrap:
----------
The amount of path cut defines, how many vertices are actually used. So the lower/upper value of pathcut will determine how many of the top-/bottom- mesh rows will be removed from the full sculptie-map. The remaining mesh is rendered as "full sculptie" with less faces.
So whatever path cut cuts away, the remaining mesh would still behave either like a plane or a cylinder. Is this correct ? Spherical and torus like sculptie maps can NOT be used for this sort of path cutting, because the mapping from the full sculptie to the partial sculptie is not clearly definable due to the mapping of the top/bottom rows. Correct ?

I also understand, that we could embed 2 or more sub sculpties into one single mesh and animate the sculptie by modifying the path cut values by script. Correct ?


Wrap:
--------
cut away the top and bottom part of the sculpt as before, and add top/bottom closing faces toward the center. Assume a sphere. Then path cut would simply horizontally cut away the poles and replace the opening by a circular plane similar to prim sphere dimple. correct ?
We would end with 3 texturable surfaces, instead of one...

End Cap:
-----------
Again assume a sphere. Then path cut would simply cut away slices from the sphere similar to prim sphere path cut. correct ? Again we would end with 3 texturable surfaces, instead of one...



If my understanding is correct, what would count against enabling pathcut AND dimple for sculpties ? Then the scenario could be:

- Use dimple to remove vertical slices for all sculptie types (equivalent to remove top/bottom mesh rows from the sculptie map)

- Use path cut to remove horizontal slices for all sculptie types (equivalent to remove left/right mesh columns from the sculptie map)

Support of partial maps follows automatically, but only for sculpties of type plane.

Does that make sense ?
I am eagerly awaiting your clearifications

Sure. Does this help? http://dominodesigns.info/images/second_life/sculptie_cuts.png Don't bother vertex counting, it's an imprecise mock up


The number of faces would depend on the LOD, map size and the amount of cut. A 128 x 128 could hold 4 full resolution square sculpties, or 16 of the 16 x 16 planar type from https://jira.secondlife.com/browse/VWR-9384 or just two 2:1 full res oblong sculpties

It would make things possible such as an item made from 4 sculpties, that had a low prim version of 1 sculptie assigned to the same map. Just cut each of the 4 to use a quarter of the map and keep their edges together during modelling.


Yes that's correct.


It's because the normal cutting shown in the picture wouldn't be possible if submaps were available on all sculptie types.


Yes. With plane and cylinder types.


Path cut and profile cut seem like the appropriate places for these settings. Dimple could possibly be done by scaling the Z component of the common point to zero.


You also get partial maps for cylinders in the V direction.

Thought about this a bit. Longer version in the attached text file (no wrap). To summarize, Domino, I think you may be overlooking the fact that the map dimensions do not generally have any correspondence with the dimensions in the rendered sculpty. In your pictures, the vertices are arranged in "rings" with equal Z axis values. In this very limited case, your cut descriptions make sense, but in the huge number of other possible arrangements, I don't think they work. You may be biased if you always use that way of defining the vertices.

Even in that case, these cuts would not be sensible for anything other than entirely convex shapes. Think, for example, of a sculpty that had three branches emerging half way along the z axis and diverging. Then the slice cut would make three new surfaces which would require separate capping to make sense.

I think it is much safer to regard cutting as applied strictly to the bitmap. It just happens that the simplest sculpt maps or a sphere or torus that approximates the mesh of the normal sphere and torus can produce exactly the same effects as the path-cut/dimple (sphere) or the path-cut/profile cut(torus) with cuts that are vertical/horizontal sections of the sculpt map. This is consistent with the cutting you propose for the plane topology. So I have suggested that the treatment of the cut surfaces should also be analogous to that produced by the normal cuts.

This allows some of the results you describe to be achieved automatically. The remainder, as well as many other useful ways of treating the cut ends, can be specifies explicitly by the sculpty designer by use of the odd numbered pixels, when they appear at the edge of cuts, in exactly the same way as the famous pixel 63 is used for the traditional 64x64 sculpt map.

This scheme is described in more detail in the attached text file.

One other point - this sort of proposal will involve much more extensive changes than the oblong map interpretation thing. It will be hard to convince Qarl that this is a good idea. I think he is more inclined to expend resources on developing true meshes rather than any further sculpty enhancements. Still, if you can do all the work and testing .... who knows.

I did consider more complex solutions that try to give a reasonable result in most circumstances, but don't think the processing hit (taking averages of up to 64 3d points per sculptie) is worth it. While it is possible to design a spherical sculptie that will always cut correctly, I think most would settle for a few good slices. Perhaps a use example will explain how I see this working:

When sculpties first came out, a lot of people made greek columns. It would be easy to do a column sculptie map representing different levels of decay on certain cuts. So perhaps 0.25 (just base), 0.5(broken in half), 0.75 (top broken off) and 1.0 (complete) would be designed cut levels for that sculptie.

So assuming that most applications of this technique will be designed in by the modeller, having restrictions on how they work in a trade for speed isn't a bad deal.

Finding the balance between features, looks and speed is something I hope this thread achieves. I think averaging the entire loop is too much, but perhaps the average of the middle vertex and vertex 0 is a good enough approximation?

But I think that way you are designing the system for one specific use and thereby excluding all other uses, while alternatives would keep all those possibilities alive.

I am not sure about the performance issue. It depends how often the vertex list is generated. I think this need be only on first rezzing, then maybe on lod changes and edits (although the vertex lists for each lod could be cached in memory). In that case, the time taken will be negligible compared to all the recalculations every time the viewpoint changes.

However, that is not the main point. The important thing, from my point opf view, is to maintain at least one mode (plane) where the part remaining after the cut is treated exactly like a whole map, including the (optional) use of the odd-numbered edge pixels to specify stitching, capping or whatever. That gives the designer complete control. Futhermore, any capping calculatiions can be done at design time, saving procesor cycles, so that the complexity of calculation would noty matter. It would allow both discrete and overlapping frame animations, as well as Greek columns with arbitrarily jagged breaks. (Growing plants are perhaps a more interesting application?)

The prerequisite for that is the odd numbered pixels are never sampled unless thay are at the edges. This has probably already been broken by the sampling stuff we agreed on that allows odd and non-power-of two numbers, but there are enough map shapes that do comply that can be used. So the remaining requirement is to control the interpretation of the cut parameters to enforce the issue.

The above would not involve any departure from the texturing of sculpties using the sculpt map as the UV map, as at present. On the other hand, the normal sculpty cuts do not use this kind of mapping. They use planar mapping despite radial arrangements of the underlying wireframe. I think you implied that you would want this kind of independent texturing applied to your cut faces. It would also be needed in my proposal to mimic the normal cuts as cloesely as possible. That would be a substantial coding effort. Would it be worth doing for the small set of sculpties it could be used for?

So I can make a simpler counter-prposal : implement only the plane topology or cut sculpties, together with enforcement of no sampling of odd-numbered pixels except as the extra edge pixels. Then leave all capping and other closing options to the designer, who can define them for every possible cut position by using the od numbered rows.

Now, of course, I am biased since all my sculpties are made entirely by calculation and not with a modelling program. So the calculations of the odd-numbered pixels seems straightforward to me. For the user of Blender etc. there is no obvious way to define the cappings to be used when his sculpty is cut. So it would be up to the ingenious writers of sculpty export tools to generate the closure pixels inside their scripts . I guess that is why you would prefer to have the viewer do it for you, even if it's only in a limited set of cases? In that case, maybe I should let you use the other toplogies however you please, as long as you leave the plane topology and the rest capable of the versaitility that can be achieved by exploiting the odd numbered pixels.

I'm not sure that this is really all that useful. The cuts in normal prims don't really map closely to any operation on a sculpty, and are only likely to look like anything but pixel-hash for sculpts that are similar to prims.

If you are only using a portion of the sculpt map, you really need to treat that portion as the complete sculpt map, allowing you to have multiple variants of the sculpt map in a single image, either as multiple "animation frames" or multiple "variants" of the map. Consider a sculpted hand... you could have (say) four positions of the hand in the sculpt map, and select portions of the map to match different poses.

So rather than using cuts to divide the map up, use something like llTextureAnimation, applied to sculpts.

Yes. The trivial use of cutting for animation would be equivalent, and llTextureAnimation would be more efficient than scripted cutting, although both could use the same composite map. Now that we expect to have minimaps, the same effects could be achieved with a collection of small maps too (but even less efficiently). However, there are rather more interesting animation possibilities that could use (progressively) overlapping segments of the map. (growing trees, crawling snakes, spreading puddles, melting faces ( ) , etc etc.)

I think the applicability of non animation cuts is also considerably more widespread than you suggest, especially in increasing the utility of general purpose sculpties (think cuttable hair, trimmable hedges, telescopic pipework, variable steps, extensible fences...*). Of course the sculpties would have to be designed specially to make the cuts meaningful, but all kinds of things are possible provided the cuts are defined on the map rather than the rendered object dimensions. (You can see in my attachment that the normal prim cuts are exactly reproduced in a mimicing sculpty by simple rectangular cuts of the mimic map).

One of the advantages could be more re-use and consequently less sculp map download lag. However whether it is worth the effort required for implementation is a different question entirely.

*...and I forgot ... crumbling Greek columns!

why not make the cuts in your sculpty program?
i dont understand why this is needed?

There'll be the usual shading issues.. So before this feature could work we would need the phong shading modified to only shade polygons that have a similar angle. So for example - the polygons that meet at the edges of a cube have a 90 degree angle from eachother and therefore shouldn't be blended or they just look plain weird.

That does limit things quite a lot. Spoiled my dodecahedron. I think we should be able to cotrol this with flags in the alpha channel bits, as sometimes want sharp angles greater than 90 degrees (e.g. between faces of a dodecahedron).

Just for fun, here is a picture of a cut torus and two sculpties mimicing it. The sculpties here were made manually, but could be implemented either with the odd numbered pixels or automatically (the flat cut only), as I have discussed.

Note first the different texturing of the cut faces. This is inspite of the fact that the cut faces of the torus have radial wirefranes. Then notice the artefact from the shading near the cut faces on the sculpties. It's not so bad in other lighting conditions mor textures, but it is a serious limiting factor. This is what 2k is referring to, I think.

The examples are using the average of the cut face (left) and an alternative that gives pointy faces (right). Either could be animated my moving the cut along to open and closing the cut, or sliding it to make the cut rotate around etc etc. The profile cut here is done with the connect-to-cetral-line method I discussed. This illustrates the analogy of the map-based cuts to the normal prim cuts.

Qarl said that the alpha channel would be used for flexi sculpties.

/me wonders why people want to cut up sculpties, when they can simply make another version of the sculpt with the desired part cut out. Or am I missing something here?

Oh yes, sculpttextures may take a few moments to load in case you wish to animate a sculpty using different sculpttextures.
Simple solution: place a hollowed cut cube nearby and decorate the different sides of the cube with the sculpty textures. This way, people will download all the sculpttextures in advance, without having to actually show the seperate sculpts themselves.

I know. I am just exploring possibilities here. He didn't say how many bits that would require (at least not as far as I recall). I guess this would only need one or two. So if six would do for flexi? I guess this has been done by somebody, becauise we saw the demo. Maybe they can say. I am pretty sure Qarl would never accept more adaptations for sharp edges anyway. To say he doesn't like them is an understatement.

Well, it's not my idea, so I shouldn't say, but I think it could save both bandwidth and texture memory. The trick you mention is fine, but occupies number-of-frames x as much memory. Also possible is more efficient use of memory by overlapping frames for some special animations.

Finally, a single sculpt map coud be used to make several shapes, saving bandwidth and memory again, even by people who can't make their own sculpties. The latter is, of course, the same reason people want cutting of regular prims. I don't see why it should be any less desirable for general purpose sculpties (such as Greek columns that can be variably crumbled ).

I can see that's going to be one of the first test sculptie chops

I think I can understand how this can be useful.. If i can manipulate the geometry with script would be great for deformations ie car collisions etc. and much faster than reloading another complete sculpt map.

-why

Wouldn't it be a very cool feature to have some form of Morphing transition between sub-sculpties ? Such that switching from one subsculptie to the other would move all involved meshpoints to the new position in a specifyable amount of time. Would that be an option for dynamic deformations, like For instance a sequence that simulates a blossoming rose ?

I have no clue, whether this is a good idea... From the ongoing discussion i have the feeling that dynamics can somehow be achieved (having the picture of the moving snake in mind)
but i have no idea, how this can be done smoothly without such a morphing feature.

just my 2 cents here

I've done a little research into how path cuts and profile cuts are handled on normal prims.

Spheres have a seam on +Y that is opened around the X axis for a path cut. Cuts from 0.0 to 1.0 travel clockwise around the path. +X is the dimple beginning and -X it's end.

Cylinders have a seam on +X that is opened around the Z axis. The path cut from 0.0 to 1.0 travels anti-clockwise around the path.

The torus path is the same as the sphere, rotating around X with the seam at +Y. The profile cut has a seam on -X with 0.0 to 1.0 going around the inside edge to the outer edge.

With sculpties, the path and profile come from the U and V directions on the sculptie maps.

Path U: Rotation around Z (seam at +Y)
Profile V: From 0.0 to 1.0 (modeled to a seam on -Z for torus)

Obviously as the modeler can place their vertice anywhere, a sculptie can have their seams all over the place. But I think the above suggestions are good defaults to keep in mind that give the closest match to existing prims.

So when we talk about a path cut, we mean using a limited portion of the U direction on the sculptie map and a profile cut means a limited part of the V direction. As U and V range from 0.0 to 1.0, there is a direct mapping to the 0.0 to 1.0 ranges of the cuts.

There's a few reasons. It makes sculpties more flexible for people who don't make their own. It helps asset server performance as it should be possible to create a wide variation of prims from the same sculptie map. This is just the first step but I can see having all prim editing options enabled for sculpties. So with a few cuts, twists etc it should be possible to build say a variety of tree parts from a single sculptie map. Imagine a forest where all the tree branches and trunks come from a single sculpt map and each tree is still unique.

It would also avoid having to cache sculpt maps on other prims just for smooth animation. A number of frames could be held on a single map, so once the sculptie is displayed, there are no further assets required to animate it.

Things like statues could use one larger sculptie map with a number of prims assigned to seperate parts of the map. This would help with aligning multiple sculpties and allow different prim count versions to come from the same map. So items could be made with a selectable prim count (imagine a 200 prim garden statue that could easily be reduced to 100, 50 or 25 via script).