Building Tool Request - Subtract Tool

From day one of my becoming an SL citizen, building has been what I enjoy the most. The tools and presentation used by SL are familiar and akin to many popular 3d editing programs. One simple, invaluable tool, however, is missing; the subtract tool.

For those among us without modeling experience, the subtract tool works as follows:

The subtract tool takes the selected object and erases it and everything directly colliding with it. This does not mean that it deletes entire objects, rather it deletes the space that the selected object previously took up. For example, lets say you have a large piece of wooden board. You create a sphere and place it in the middle of the board. If you subtract the board, you will end up with a hole in the board where the circle used to be. (I know, I know, you can do this with hollow, but hollow is a poor substitute for legitimate subtraction)

Not sure if this is a feasible addition on the part of the developers, but it would sure add a LOT of new ability for a rather minute addition of one tool.

Any thoughts? Comments?

Hehe when I first started SL I spent a while searching around trying to find the subtract tool. (just ask chef)

I dont think you will ever see a subtract tool because the engine would probably have to try to model your resulting board-with-a-circle-cut-in-it using the prims available normally. And figuring out what prims and parameters could be put together to create the desired shape would be hard, if not impossible (or you might get 1000 tiny cubes made or something)

If you look at all the prims they are pretty low vertex, simple meshes. If SL was to do real subtract by modifying the mesh directly and adding vertexes, they would probably want to change the prim tax to a vertex tax

So anyhow, I'd love to have a subtract tool but I'd expect we can't. Maybe LL will suprise us

Yes it would be nice. But then it would go into another beating on more dead horses concerning server stabilty->cost of servers->taxes->well..

Yeah, if we had a subtract tool, you would probably have to count each and every subtraction against the prim count. My experience with subtraction tools is that they severely impact the graphics processing speed because essentially every time the view changes the card has to re-do the whole process of drawing the original shape and subtracting.

So for us to get this feature may take a few more generations of upgrades in graphics cards.

Actually, I think it is a good application for Darwin's invisibility bit (It think.. I used my formation to do that before....)...

Ill have to agree with the party line on this one.
It would be nice to have NURBS or .obj import or even simple splines for that matter.... but it would also be nice to have a million bucks and a direct line to the president. :/
SL is pretty amazing with what theyve given us so far you really can build almost anything if you get clever with prim placement and dont mind spending tons to rezz a complicated object.

Chip Midnight explained it pretty well. What we would all *like* is constructive solid geometry (CSG), which is what you get in every 3-D game I've heard of (except the old raycasters like Wolf3D.) In CSG, objects are stored as vertices and faces.

In SL, objects are stored parametrically, i.e. this is a cube, its location is this, its dimensions are that, its rotation is (x, y, z, i), its faces use textures with keys a, b, c, d, e, and f; it has extra parameters j, k, and l. (cut, hollow, hollow shape, etc.)

Evidently it's more efficient computationally and bandwidth-wise to use parametric modelling rather than CSG modelling. When you think about the extraordinarily complex shapes you can get just by putting a few simple geometric shapes in the same place, it's easy to see why.

Maybe at some point in the future they'll give us the ability to carve up primitives in arbitrary ways. For now, there are ways to significantly twist and distort primitives - making them hollow, changing the cut start and end, the dimple start and end (spheres), changing the interior shape, etc. They are somewhat limited. A few extra controls, like hollow center offset, would be nice.

That is, I believe, a very accurate assesement Huns.

And I think some extra controls are the way to go - Hollow offset sounds great (how many axis should you be able to offset on?), as would an option to rotate the Hollow part.

Those two would give near the functionality of the subtract tool.

I, too, looked for a subtract tool when I first started building. But while there are shapes that just can't be made with the current system (or that can, but only by using a lot of small prims to approximate the shape needed) the current system is pretty darn good.

That said, I want subtractive geometry.

You could do subs with parametric definitions of prims just by giving each prim a mode type like Subtract, Exclude, or Xor. To really work well, however, there would need to be improvements to the link system. We would have to have the oft-mentioned (mostly by me) tree links. [A prim can have a number of linked "child" prims, each of which can also have their own "children".]

Then the effects of a subtraction, for instance, can be limited to a group, which can be part of a larger group.

So rez a wall and a cylinder and link them together. Make the cylinder Subtractive and position it so it intersects the wall, making a round hole in it. Now you could make a long skinny prim and stick it through the round window without it getting cut by the cylinder.

If you select the wall link, you can see the glow-outline of the cylinder, even though it's not visible. With this new linking style, I think a link-only world view would be nice to have, so you only see the objects that are part of that group. It would make editing them easier.

I better stop. I keep adding features!

One big issue with that system Tiger is Collision.

Suddenly (with subtractive geometry) you can pass through an arbitrary space in the object. Having to support this would really slow down physics, collisions and the game itself.

No... It would actually be faster!

The data that describes the subtraction as sent over the net may be two prims, but just as with all geometry in the game it gets turned into an actual solid on each user's machine. It has to, because video cards just want a whole bunch of triangles, not prims. (If a cube is primitive, then triangles are downright PRIMEVAL! )

In other words, a sphere's description might be it's position and rotation (and cuts, etc)... But it gets turned into a bunch of "trishapes" to hand off to the graphics card. A subtraction would just be a different way to describe the collection of triangles the graphics card needs.

Collisions are also handled by Havok on the trishape geometry, so there won't be any difference there. And a cube with a round hole in it would probably have fewer triangles in it than a sphere, so subtraction doesn't necessarily add graphical complexity. (Though, admittedly, it CAN, but so can a whole lot of prims... Which would be needed to make the same shape.)

In fact, because the resulting shape will have no faces passing through each other (in the final trishape form), collision will be more robust with subtractive geometry... As compared with building the same shape out of multiple intersecting prims, which can give any collision system FITS.

All thats needed are new translation functions that convert the prim subtractions into actual geometry, and that's fairly straightforward.

The biggest problem is making them easy for us to edit, which is why I mentioned treed linking.

Id be happy with an offset hollow option. I think part of the reason the game is set up the way it is, is so that we will have to pay more for more complicated and cool objects.

But we don't... Not unless it means using more prims to simulate a difficult shape. And that is counter to the very reason there's a tax in the first place -- To keep a limit on the number of prims in the world and prevent clutter from slowing the game down.

Yeah, Linden Labs can keep adding more and more "tweek" settings to the prims we have, such as some way to offset the center of a hollow, or choose the face, or the angle... But that keeps adding to the transmission overhead. All that information needs to be sent from server to client. Going now to a subtractive geometry would provide infinitely more customization on the part of the builders, but almost no additional transmission overhead.

You would argue that sending an extra prim with all its parameters is almost no overhead compared to adding a couple more parameters to existing params?

I'm not countering it, just wondering where you get that information? It doesn't seem we have enough information to make that determination. We sorta just observe the behavior not the process. You may be right, I don't know.

It depends on what the objects are, of course...

On an individual accounting, adding a new modifiable trait (like the requested hollow offset) would take less bandwidth than sending two whole prims (one for the object, and one to cut out the offset hole).

BUT, remember that every other prim in the whole world will get the same offset values, whether they are used or not, and THAT would take more bandwidth. There are a lot of prims out there.

It's a balancing act. You don't want people to HAVE to use subtraction to get basic shapes. That's bad for bandwidth. But you want to keep the description for a prim as small as possible to lower the bandwidth burden on simple cubes and the like. If Linden Labs were to lock the primitive descriptions as they are now and add subtractive geometry, everything in the world would remain unaffected (any change HAS to be backwards compatible) and whole new classes of objects could be built -- Smaller than ever before (in bandwidth).

Then again, they may have come up with some spiffy data-packing on the primitive descriptions (I can think of a few ways) and so the whole bandwidth topic is moot. Subtraction would STILL be nice to have.

I have been asking for this for a LONG time... not on the BOARDS or anything... ^_^. This would be a GREAT tool... but I dont think its going to happen =(. The only reason SL is able to stream so well is because it gets info on what the different prims stats are- it doesnt have to download custom models.

Lance LeFay:
It wouldn't be streaming custom models, it would still only be sending primitives. The difference is that some prims (and I'd suggest only one per linkage to keep things simple) are marked as subtractive, and they cut into the other prims in their linkage on the end user's machine.

Actually no you couldn't The whole point of a parametric object is that the engine doesn't need to know where every vertice of every object is... all it needs to know is where it is in world coords, its rotational offset from the world axis, and the numerical inputs for any cuts, hollows, twists, or whatnot. Think of prims as little recipes that the client app already knows how to bake. The server doesn't have to explain to the client how to make a sphere. It's built in. Now if you wanted to be able to do subtractive geometry, suddenly the engine needs to be told how to bake the cake, because arbitrary new vertices and faces need to be created so that your graphics card can render the resulting surfaces. You've just defeated the purpose of parametric objects because your client has to tell the server how to make the object you've created, and then the server has to tell everyone that comes into eyeshot of it... that's a whole ton of extra data that doesn't need to be there with the current system. It all comes down to the fact that everything has to stream in as near to real time as possible. We can dream though I wouldn't hold your breath for subtractive geometry in SL any time soon.

Boolean operations aren't trival. It could be possible to have the server just stream the prim locations with added pos neg tags and make each client app do its own boolean operation to create the new vertices and faces, but because every object can be moved in real time, everyone's client would have to redo the boolean for every frame... and there might be dozens of subtractive objects within view range at any given moment. That would be a huge load on your processor. The only way I could see this happening is if boolean/CSG support is built into next gen graphics cards, and even then I'm not sure you'd see it in SL... a static world is one thing. A world where the recipe for your cake might have to change on every single frame is another beast entirely. And we haven't even talked about UV mapping or textures on those newly created faces.

I know I'm defending an idea that won't be added to Second Life for a loooong time, if ever, but....

Chip Midnight:
Actually that is what the server is doing. There are basically two requirements for the encoding of the 3D data:

1) What is transmitted over the internet has to be as small as possible. This means (in this case) parametric encoding of the data -- Describing a sphere by it's position, radius, etc. Subtractive geometry is good here because it is possible to describe complex objects that would require many standard primitives to build, but with fewer pieces. (And therefore less data.)

2) What the video card needs is triangles, and lots of them. It is the client application's job to translate the parametric information into lists of vertices, each trio of which (or less, if something called tri-strips are used) forms a triangle. The sphere that takes just a few simple numbers to describe will be turned into many, many triangles to approximate smooth roundness. Not only that, but Second Life uses LOD (Level Of Detail) to make objects far from the camera use fewer triangles. That lets us get more things on the screen for the same CPU power, at the price of re-translating the parametric data into different triangle groups. The parameters we have now to make the twists and cuts and so forth all affect the client's translation into triangles of the 3D data. Subtractions would be just another translation algorithm.

Oh, and the texturing of the new faces is very simply handled: It uses the textures of the cutting prim. So if we have a cube, and we cut off a corner of it with second cube, the new face that is created gets the texture that was on the intersecting face of the cutting cube.

The biggest drawback I've been able to come up with is the possibility of "degenerative" objects. If you were to cut a sphere with another sphere just slightly smaller and twisted, a completely accurate cut would be a mess of pointy little triangles! For efficiency, accuracy would have to be dropped in such extreme cases. Perhaps the cut can be calculated before the spheres are fully translated into their final triangle shapes. That's an advantage this system has over standard 3D engines, at least...

Sheesh... I wish my thread on a new rating/voting system was as active!

I agree with Tiger on this. Instead of sending 10 prims to make an odd shape, it sends 2. Just my 2cents.

Yes, that's all possible... but the point you're missing is that those kinds of subtractive operations in which new geometry has to be created are not at all trivial. I don't know of a single application that can do this in real time with just two prims, let alone dozens. Look at the apps that have this kind of capability now... every major 3d modeling app can do booleans (overlapping volumes are subtracted or added to each other). In all of them you position your objects and then hit a button for the app to make the calculations. It's not instantaneous. 3ds Max can do animated booleans that recalculate on every frame, but even with simple objects the framerate in viewport playback isn't near fast enough for a game environment, and the minimum system specs for max are much higher than SL's. Game level editors can do CSG but the levels have to be compiled (so a BSP tree can be created). perhaps when we all have 64 bit pentium 8's Real-time subtractive geometry will definitely happen in the future, but it's not viable for a game engine yet. Of course, as always, I could be wrong

The calculations to find the intersection points of two surfaces are trivial, and the subdivision algorithms to permit LOD are already in there. It's not that computationally expensive.

Since I'm proposing that subtractions are only used as part of a link (since that makes them so much easier to control) it won't be possible or necessary to animate the cut. (No moving holes in a surface!) So the calculation need be done only once as the objects' parametric descriptions stream in, just like with twists and so forth.

When editing, the cutting object will have to be fully visible. It won't be till you link it to its subject that the cut takes place. This is mostly for the simple fact that you need to be able to see it to manipulate it, but it also prevents the need for constant updates. (Though I think just about any machine that can handle Second Life well will not have any trouble even with live editing of subtractions... Except, perhaps, in extreme cases of multiple cuts.)

I imagined that, with two cubes, you set one to subtract and its edge-glow changes to red. Then you position it so it passes through the other cube and link them together. The red-edged "knife" cube vanishes, leaving its texture on the other cube where they intersected. With the link selected, you can still see the red outline of the "knife" cube, though the prim itself is now invisible. Unlinking the pair returns the "knife" to normal visibility, though as long as the subtract setting is on, it's outline will be red.

I'd love to hear a definitive yea or nay from Linden Lab, but it's probably just a "for future consideration" sort of idea, and they'll never comment.

I think it is more computationally intensive to create the new polygons of a randomly cut primitive than you give it credit.

You take a cube, you take a sphere and make the sphere 'negative' and cut out part of the cube. What has to be calculated is a suddenly new and very different from any existing mesh, set of polygons that is the new outside of that cube. A cube that previously had 6 sides and 6 (maybe 12) polygons, now has an arbitrary number. Just looking at 1 side that used to be really simple, a square - maybe 2 triangles. Sudenly instead of 1 polygon that flat surface must be many, many polygons to simulate the curve where the hole is, which means adding LOD calculations too. And then you get the inside of that cube.

When you really think about it you can see that a cube with a sphere cut out of it is potentially many, many more polygons than a sphere and a cube combined. And calculating those polygons 'on the fly' is very, very tough.

Also the prims used are used because they are natively supported (I think) by OpenGL. Your new cut prim is not, which means lots more work.

==

Now that doesn't mean I wouldn't like subtractive geometry. It would be hecka cool. I just think there are simpler ways to get similar results.

You know what else I would like to be able to rez as a prim? A surface patch or a rotational patch. Bandwith wise a rotational patch is extremely simple to describe - 4 points. If you add params maybe there is angles rotated, but that is about it. Suface patches are a little tougher at 16 points.

They are both computationally intesive though to actually draw, comparatively at least. I would dread walking into an area with 100 rezed surface patches.

Ama Omega:
I think you are making it out to be tougher than it is. Sure, I'd HATE to have to do it by hand, but a computer can handle thousands, no problem. Just remember just how much it's doing already. Modern computers can handle it, they really can.

My knowledge of OpenGL is very rusty (I've been stuck using DirectX crap at work) but you can do Constructive Solid Geometry (CSG) with it. (That's the technical term for what we've been talking about.) There are pre-built libraries to handle it. Though of course, those are of limited use to a commercial application like Second Life, unless there are licensing options.

It's the in-game interface that's the hard part, but as I've said, I think THAT is doable too.

What do you mean by "surface patch or a rotational patch"? I'm not sure I follow. By surface patch do you mean NURBS? If so, yeah... We're not going to see THOSE in the game -- The editing of which is far, FAR beyond the ken of most SL players.

Just wanted to post this and say "I told you so! neener neener" Okay, I feel much better now.