Building Revolution! :D Idea to impliment mesh

Ok, from what I understand, to impliment mesh manipulation on the prims wouldn't require much more data on the interface than what is already there, however the streaming between client and server would be the issue. So here is my idea!!

Add a button in the edit box (the window that pops up when u right-click and hit edit), or the pie menu, that allows a user to bring up a mesh manipulation window. This window would bring up a 3d Mesh model of the selected prim in a seperate window like the texture windows work or color selection. Then the user could edit the mesh in there, everything would be client side UNTIL the user clicked "Apply" or "Ok" at which point the data would be sent to the server and the prim changed in world. Voila, Mesh implimentation with very little server load! ^^

Granted the data sent by mesh prims would be slightly higher, but it wouldnt be as bad, because think about it. If we have the ability to manipulate the mesh of a prim we wouldn't have to use 300 prims to get the same effect as 2-3 mesh prims would do. That would cut down on the server load a great deal.

There could even be limitations implimented to the mesh to keep people from abusing them x_X. I mean you have limitations on prim size, 10x10... hehe and linking... But even with limitations, the ability to edit the mesh of a prim would improve the overall builds in SL so much

I wasn't talking about the ability to import outside builds x_X I meant the ability to manipulate mesh on prims IN GAME o.O

The editing of a meshed object wouldn't not be a problem, and could be done in-world more easily than in a window. It is the large amount of data it would take to describe such an object that is the problem. That data has to be sent to every client that comes near it.

The obvious solution is to use spline-based surface desciptors. Then the data to define the mesh is just a few spline points and handles, and the clients can build the mesh on their end from that. Added bonus: faster machines can render the mesh with greater detail and smoothness, while slower machines can simplify it for faster speed.

Of course, manipulating spline paths in 3D is a bit more of a challenge to make accessable to the general public...

I would settle for editing a 2D spline that would then be extruded along the face of a prim.

Going right down the line...


I realize that. However, this is probably the closest you're going to get in the current timeframe, because true mesh editing is more of a long term deal. Since it would require a (major) rewrite to the content streaming system, very likely being added above prims at some point, it's still a ways off. We're still having trouble with how assets are streamed to the current client.

As technology improves, 3D mesh manipulation of some form is all-but a certainty. My guess, however, is Second Life will provide import support as opposed to a raw editor. This would keep overhead down, because there are plenty of good, free tools out there. Not only that, but 3D content creators, like myself, are typically more familiar with their native environment than coping with a completely new interface.

But again, this is long term.



I would be happier if they just gave us real-time bump and normal mapping. Unfortunately, the surface calculations for these aspects would need to be accounted for in the physics system... which is another reason why we don't see more advanced support for this stuff yet.

LL still needs to get on top of current projects first.



I think the jury is still out on in-world editing at this level, and just how much of a benefit that would (not?) be. It would require a pretty large commitment on LL's part to incorporate an in-world system, though a lot of what's needed is probably already in place. Most pointedly, though, bringing the current engine "up to par" with current industry methods of rendering would be a HUGE money and timesink, and that's just not something that I see LL being able to commit to for an extremely long time, if at all.



Just so we're on the same page... are you talking about NURBs here? If so, I agree - NURBs rock as far as fluid geometry is concerned.

But again, we're right back to square one. As you mentioned, how would we make that user-friendly? The simplest answer is this - many external tools provide algorithms that will convert mesh behavior to NURBs. Asking LL to add such an algorithm would only increase overhead, and again I feel this is less of a necessity.

In closing, I know (from the feedback to my importer) that many residents and Lindens alike would like to see 3D mesh-or-NURBs based models in-world. However, until that becomes a reality - your best bet would be to either learn to love the existing system or, if you feel a mesh would be more appropriate, use a tool not unlike the one I developed for imports.

Hehe, I do love the system they have already ^^ I was just offering an idea for the future. And I do realize, and agree, that its not something we'll see for a while. But maybe its something to put on the to-do list ^^. Thank you for your thought out comments, gomez, it was very informative.

meshes instead of prims? is LL using per poly coldet? converting the prims to polys on the fly? one thing that pops into my amateur head that would be added to the cause-and-effect list.

mesh to NURBs? is there a converter that doesn't create a bewildering array of NURBs patches? talk about a UV nightmare.

i say feed us some more parametric options. and maybe an editable history to go with it (ala Pro/E, SolidWorks, etc).

been awhile, but last time i looked at this (normalmaps), the issue was graphic slight of hand and not actual displacement for physics systems purposes. what am i missing? the only thing i can figure is that these tricks would require players to have beefier videocards and SL to pony up for increased texture storage (thereby increasing lag). help me out.