Subtraction primitives

I would like to see subtraction primitives added to the 3D editor, so that mass can be removed where there is an intersection, the order of object creation.

The Lindens haven't been totally receptive to this suggestion in the past, because it's not really practical.

You see, SL doesn't use true vertex or face-based primitives, that's just what we call them. Objects in SL are made up of parametric models. The client knows what a box is, and so very little data needs to be transmitted.

There's no reason why the Lindens couldn't add a lamp or teapot "primitive", aside, of course, from the fact that it'd be stupid.

To implement true CSG subtraction and addition functions would require a significant rewrite of the way SL draws objects, and an increase in data by at least several hundred percent.

> To implement true CSG subtraction and addition functions would require a significant rewrite of the way SL draws objects, and an increase in data by at least several hundred percent.

That may be true, but it doesnt follow from what you're saying.

You're saying that a primitive is transmitted to the client as something like [ iPrimType, vPos, vScale, rRotation ]. The client takes this information and does what it takes to get this rendered and displayed on the screen.

There's no particular reason why boolean prims couldnt be transmitted to the client. Bandwidth would be similar to normal (except the single extra "boolean" on/off bit). The client would obviously have to know about how to render it.

Physics could be a pain perhaps, depending on the extent to which Havoc could handle this natively.

Azelda

This thread gets reposted every 2 months like clockwork. LL should explain what the deal is with this and sticky it.

Azelda - I believe the problem lies in 'doing it right'. IIRC it is not only the graphics engine that is built around the parametric model, but the physics engine. And arbitrarily odd shapes (as could be created by true CSG) would be incredibly hard to do. And really, no one wants this feature if they can't actually walk through the negative space created by the objects.

Also, just because the data could be sent easily doesn't mean it wouldn't require a significant rewrite of some graphic engine code.

I agree with Azelda, these negative shapes could be downloaded exactly as implemented, with no change in bandwidth costs.

As for rewriting the client, it is doubtful to me. As for the issue of "true CSG", the argument bears little weight. If the client knows how to render these various shapes, and how to split them and twist them etc., these are NOT inherently built into the OpenGL engine, although I understand how you can use shape templates and such in OGL and C++. But the whole science of rendering the shapes in the first place was an acheivement, so why can I not simply suggest that they take the next step by offering subtraction?

Hard to do? I'm a software developer, and I've even done some tinkering with OpenGL. I've also been very well exposed to the original version of UnrealEd, and as you know Unreal had the most beautiful 3D engine of them all, so forgive me if I'm a little spoiled.

But I didn't ask if it was "hard". I know for a fact that it is doable, and I was making a feature suggestion.

As for the issue of being able to walk through subtraction brushes, that is completely a non-issue and outside of the broad scope of the suggestion. It's like responding to the suggestion, "I'd like to see some high quality prefab vehicles" with "Yeah but where are you going to sit?"

Actually it is more like responding to "I'd like to see some high quality prefab vehicles" with "do you care if they don't actually move?"

You missed the point. Subtraction brushes should do something in the engine that does not actually add geometrically avater-blocking content. "Light"-type material, for instance, can be walked through. This is a minor issue of implementation, and even if all prims have to be tagged with a boolean value in the engine as to whether they respond to collision detection, so be it. It is still doable.

Actually, before you start telling long-time users that they are wrong and missing the point and that you know how the engine works...

Light-type objects are quite solid, I assure you.

Now, that aside.

The problem is you aren't looking at the whole picture.

Yes, theoreticly, you could set it up so that an object had two completely seperate sets of parameters... its visible ones and its bounding box ones. In fact, something similar has been proposed for vehicles from time to time, to try to lighten the load on the physics engine.

Nevermind the fact that if you have to have two sets of these parameters for each object you have (given the volume of prims) made a fairly sizeable increase in the amount of bandwidth needed.

But what you're asking for involves a good deal of other stuff I don't think your taking into consideration. There is a lot more to the physics engine than if an avatar can touch it. Can other stuff touch it in that subracted area? Does it touch the ground in that subracted area? Will it volumedetect in that subracted area? What's its center of mass? What's its mass, for that matter?

Could the lindens just say "screw it" and forget all of that? I suppose. But then you would have a piss-poor half-assed implimentation of it, as it would be completely unusable for almost everything people would actually want to use it for... namely, building stuff that either AVs interact with (structures) or that the physics engine has to keep track of (Vehicles).


See, thats the thing. Yes. If you wanted to potentialy introduce more needless bugs and lag in an already laggy game, yes, you could probably hack something in. Would it suck? Abso-fricking-lutely. Whats the point of building big hollow things that cant do anything? Just to prove you can build big hollow things?

And you missed the point, too. I was referring to semantics. People may be veterans of the game, but I am no newbie to tecnnology or the English language.

My apologies, what I meant was the "Phantom" type objects.

Uh, why not simply have a boolean, like I said, of "prim is bounding"?

I do take it into consideration, but that's exactly why I said that the broad scope of the question is too broad for specific petty details, unless you want to engage in them all.


Do I care? Let Linden make prefab decisions on such things and just offer something.

Okay, now you have a valid argument.

More valid arguments.

I'm standign on a "light" prim right now. I'm not passing through it.

There is, however, a flag called "phantom". This is not the same thing

Yes, I made that correction above, but you beat me to it.