The ability to do subtractions or voids to primitives.

Pretty self explanatory title:
I would like to see the ability to do subtractions or voids on primitives, not unlike the "hollow" ability, but it would be much more versatile. Place a void object at the point within another object, and then a button "make void" Would give us a lot more versatility in object creation and not really require any new basic prims. Seems like it would also cut down on prim load as well, as you would not have to use multiple prims to create some fairly simple objects. Good example would be a wall where you don't want the window exactly centered as you have to deal with now, using the hollow command, now you have to use 2-4 prims for that, where with creating a viod where you want it, you could do it with one, or possibly two, if the "voided" object is still counted in prim use. It would also allow for multiple holes or voids in an object as well.

Yes indeed Cash!

A void can be implemented quite simply as a 3D graphics portal volume, the vertices of which are defined by the mesh created at runtime by the voiding prims. So, this is an excellent idea, as long as you accept that the void that you've scooped out counts against your prim allocation, 1:1 proportional to the number of prims in your voiding object. That's because the voiding object is actually carried along by the voided object, since the portal volume has to be generated at runtime.

It's also possible to implement this without carrying along the voiding prims at runtime, but that becomes equivalent to dumping out a mesh of the voiding object with a fixed resolution and then carrying the mesh along to define the portal. In most cases that would not be as efficient as carrying along the geometric prims, since for regular geometry it's usually hard to beat a mesh generator.

The only thing to add to this is that the surface that has been voided out can be an opening into the voided object or a deformation of its surface --- both options are valid and useful in different situations, so this would need to be selectable. The opening option is just a hole, and portals are pretty good at giving us holes without extra help, lol. The deformation option is also easy to implement though, because the mesh over the voided area is simply copied directly from the voiding or voided object over the area of intersection --- another selectable option.

Paging Chip Midnight to explain for the 10,000th time why this is not going to happen.

Chip may in fact believe that this is never going to happen, but it is very different from what was suggested earlier (trying to distribute and cache arbitrary meshes). It adds computational load to the client side, but no significant additional bandwidth. Mostly I would guess it is an effort-to-implement issue.

Vaguely related: I would like the ability to add many many vertices to rectangular surfaces so that they respond naturally to the kind of lighting that SL provides. Spheres look great (for just that reason), and I've never heard anyone complain that they are more expensive than cubes to display.

Shhhhhh .... if anyone hears you and actually understands that prims like spheres can generate huge meshes in the client, they'll no doubt jump in delight at finding yet another opportunity to shout "Impossible!".

I guess it's just easier to repeat someone else's falsehoods than to think about how something is really implemented.

You're dead right though. That would work fine, and it's not hard to think up parametrized but non-textural surface distortions to do it.

I surrender, Huns Let 'em dream. Someone from LL should write up something about subractive geometry and non-parametric mesh objects and sticky it.

And if they did, it still wouldn't mean that if some better idea comes along to overcome the stated difficulties then it isn't valid.

Quoting previous dogma without bothering to address technical details has limited value. And appealing to authority has no merit per se.

Hey, maybe you should keep posting about it, using the most complex jargon you can possibly use!

And if we told her that Havok would never be able to handle calculating the collisions for arbitrary concave objects she would just say, why, use a bounding box, I'm sure no one would mind floating in the air, 5 meters away from their actual object
I love you morgie
You're so cool

Hell, if Philip's own words on the matter aren't enough, what on earth am I going to say to change anyone's mind? Subtractive client side geometry is certainly far more likely than uploaded mesh objects... except that generating the resulting arbitrary mesh in real-time is problematic, not to mention UV mapping and physics. But whatever. I wouldn't mind being pleasantly surprised. Go code it up, Morgaine

never mind

100% correct, Eggy! No folks, Eggy isn't clairyoyant, it's just that we were chatting about precisely that when he came visiting here yesterday, haha.

There are always solutions to simple things like mesh overheads, it just requires normal engineering tradeoffs to be applied. The coarse-resolution bounding box is only relevant until a finer one has loaded of course.

A good engineer is not restricted by what exists, and even less by what people say is the limit of possibility unless they give precise technical details of the showstopper. Furthermore, even that merely moves the discussion to finding a solution to the new problem they've identified, so it's only a temporary hitch. Problem solving is fun.

Feeling restricted by what you're given and putting up with it is for slaves. And living with what one has because someone else said that that's all that's possible is for non-techies with an inferiority complex. It's not even valid logical reasoning, ie. it's appealing to authority.

LOL, we're not going to reach the stars folks if we don't even want to look up.

Though subtractions would be nice, I don't think you've thought about the performance issues entailed by this proposal. Though some designs would definitely be optimized if subtractions were allowed, others would most definitely not be. In fact, I can easily imagine some designers, be they new or merely naive, who would create structures with negative prims that are even less efficient than the non-negative alternatives. In the end, the necessary bandwidth would probaably only increase slightly, if at all.

However, the real concern becomes client-side load. You snidely dismiss this concern as being unfounded, Morgaine, but that's a foolish thing to do. There are very few rational arguments you can make to persuade me that requiring the client to subtract two or more prims wouldn't increase the load on the client. Not to mention the necessity to improve Havok's collision handling. It is not trivial.

Oh absolutely. But that's why LL validate prim constructions and distortions before allowing them. They do this right now --- you must have seen objects disappear before your very eyes with an "illegal geometry" message when you've been playing with the distortion sliders. There's no reason to believe that LL wouldn't apply similar validation to voiding intersections. They know what their renderers can handle, and pre-validate accordingly, so wacky geometries wouldn't make it through.

Actually, I think you've mixed up a couple of threads, Ardith. I never said that voiding wouldn't increase loading on the client side, let alone snidely.

In fact I gave two possible implementations, and one of them entailed carrying along the prim-based voiding object so that it's pretty obvious that this would require extra client-side processing, not just of the voiding object but of the voiding intersection as well. I even mentioned the extra processing for handling the texture on the voided surface for deformation-type voids. So, you seem to have your attribution wrong.

Cashmere didn't say anything at all about client loading either, and my post just accepted that it could be done and provided some ideas for how one might go about implementing it. Looks like crossed threads.

I apologize for putting words in your mouth, Morgaine. I had indeed become confused. However, you didn't completely eliminate my concern with regard to new users and negative prims. Even now, it is completely possible to produce horribly twisted and distorted prims, such as tori, which can have a detrimental effect on performance if abused. What happens when someone produces a physical object with 2 tori that have been advanced cut, twisted, hollowed, &c., and then a whole slew of negative tori that have been advanced.... How big of an impact will this have on performance?

I absolutely support the Lindens implementing some sort of prim subtraction operation. I just don't want to wake up the next morning and see that performance has taken a huge hit as a result. I also think that the Lindens should concentrate on eliminating other bugs before they implement such a relatively enormous change.

Sure Ardith, that's a perfectly reasonable concern you express.

I don't think that there are any major stumbling blocks in pre-validating distorted prim topologies, although perhaps a mathematician can provide us with more information on this. I do remember it as a pretty complex subject though, and certainly LL's set of transformation sliders are pretty wacky, so there is certainly room for hidden issues in this area. Of course it's not a showstopper though until the problem is proven to exist, and that no fix is possible.

On the performance front, this is actually quite easy to address automatically, because prims have a built-in CLOD system --- the surface whioh they define mathematically is tesselated in each client into different numbers of polygons depending on the required visual resolution. There's no reason why the algorithm which determines that resolution shouldn't include a factor dependent on prim rendering slowdown. If the render time is measured, this could compensate automatically for any problem related to processing overhead introduced by features like voiding or any other feature introduced later.

The calulations required to generate a boolean mesh are not at all trival. The problem isn't with any single instance, it's that at any given time there could be hundreds or even thousands of these objects within your draw distance. Your client would have to generate the mesh on the fly for each and every one. Good luck

Well, no, you'd implement it on a per-object basis, possibly even for just a single pair of primitives.

Azelda

It already does generate the mesh on the fly. Prims are just client mesh generators.

If a prim-voided object carried its voiding prims around with it so that void resolution is as dynamic as prim resolution (ie. you see more polygons in the void when you get closer), then this would at a minimum add the overhead of generating the voiding prim meshes in the client just like ordinary prim meshes.

So, if one object used another identical object as a voiding volume (eg. two boxes of identical size, the second one being used to lop a corner slice off the first one), then the voiding mesh generation overhead would be exactly 100%. And then on top of that, one has to consider the intersection calculation overhead, the void tesselation overhead unless it's picked off the voider, the void texturing overhead for deformation voids, and the portal creation overhead for wall-penetrating voids.

It's hard to estimate how much total overhead this would create, but always remember that it has to be compared not against the processing required for just the one original unvoided object, but against the processing of the composite set of prims that would be needed to construct the voided shape in the absence of voiding.

There's a SIGNIFICANT difference between pre-programmed single-meshes, and having to calculate boolean meshes of an indeterminite amount of detail. Say I punch five twisted, hollowed, torii shaped holes in a twisted, cut square prim? That's a LOT of computation for one mesh.

SL prims don't use preprogrammed meshes. They regenerate them on demand from the basic geometric algorithm given by the prim type and parametrized by its various sliders, tesselating on the fly depending on the resolution required by distance, size, etc. We can see it in action before our very eyes.

Nothing new there, it happens right now, and it applies to the visible prims and to prims used for voiding alike. If the two identical boxes of my previous example each require an amount of processing X and hence 2*X for the pair, then if one of those boxes is massively distorted and now takes 5*X processing, then a voiding pair of identically distorted cube will still take exactly twice as much prim processing, namely 10*X. No magic. If you pick more complex objects, they will require more processing.

A much better question is by how much the intersection calculations will become more onerous as as you apply more prim distortions. Indeed, if the maths indicates that the growth in complexity is O(huge) then a compromise might have to be found to mitigate that, for example, to allow voiding with undistorted void objects only. Or even insist that both objects of the pair must be undistorted!!! Admittedly that sounds like a terrible restriction, but it might still be worth it. It's easy to see large numbers of very appealing voided shapes that this would still allow.

Incorrect. The recipes for the various prim types are hard coded in the client. They are not generated "on the fly." The server simply communicates to the client what type of prim it is and where to put it. The different LOD resolutions are also hard coded, not generated on the fly.

I think you were both trying to say the same thing.

I think it's more likely we will get mesh before we get this.

I think Strife is very close to the truth when he says that we're both describing the same thing:What I call algorithms, you call recipes, that's clear, and we're both saying that they are already built into the client. Likewise, we agree that these algorithms in the client get parametrized by information originating on the server, ie. I mentioned the setting up of the parameters on Edit sliders etc and you mentioned the communication between server and client to get these parameters when they get applied, in the client.

However, where we differ is in our interpretation of what happens from there: I have no internal knowledge from LL, so I am assuming that they would code this like I would, namely that instead of having one very large pre-generated mesh per rezzed prim representing maximum resolution which is then CLOD'd down when less resolution is needed, that instead they tesselate the mathematical surface on demand ("on the fly", in accordance with distance, size, etc.

Both approaches have benefits and both have disadvantages, like everything else in 3D graphics.

The pre-generated maximum mesh is much faster to process, because the full maximum-size mesh is generated "on the fly" (as in the other approach) only once, ie. when the object parameters are downloaded and cached. However, this solution has a very large permanent memory footprint since the stored mesh is always max size, and remember that if there are 20 differently distorted torii (say) in your cache then you require 20 different maximum-size pregenerated meshes in your machine because in general they will have almost nothing in common with each other if their creators have been playing a lot with those deformations. Choosing this option makes sense if you are more interested in speed than efficient memory usage. It's a very good choice then.

The tesselate-on-the-fly approach differs in only one respect, and that is in the fact that what the other approach generates only once all the way to the maximum mesh size, this dynamic approach does repeatedly whenever a different resolution is required, and it does so only to the extent needed, not to maximum mesh density. If you have 20 differently distorted torii as before, you'll get 20 much smaller meshes in memory, and they'll grow and shrink as required. Choosing this option makes sense if you are more interested in efficient memory usage than speed. It's a very good choice then.

Which approach is actually being used is a simple matter of factual information. If you have LL dev information that they pre-generate their maximum-size meshes only once when the prim distortion parameters are received from the server then that's great, that's what's being used. You didn't say that you had such information though, so we're both merely guessing at this stage. I guessed that it's dynamic simply because I see the outlines and textures go fuzzy when I move to and fro, and I wouldn't expect that lag in visualization if the meshes were already available at max res.

It would be so much easier if LL had a bit more of a technical presence on this forum. In the absence of that though, we could just ask them directly.

Notice that both approaches are pretty much identical in terms of the geometric surface tesselation code required in the client. Tthe only difference is that one approach generates that mesh only once, and the other repeatedly. In terms of the original subject that brought this analysis about, ie. voiding, under your interpretation voiding has even less CPU overhead than under mine, since a maximum sized voided mesh would be generated only once, at the time of rezzing the voided object. And that would please the proposer of this voiding thread a lot, no doubt.

I got ya, but I don't think this is how it actually works. You're thinking that the entire prim and all the polygons that make it up are being derived from an algorithm. What I'm saying is that the recipe for a sphere is hard coded with a specific number of polygons, and that there are versions for each LOD, so the actual topology of the primitive isn't generated on the fly, but according to a specific hard coded topology. Of course, as always, I could be wrong