Modelling improvements

There are some modelling capabilities absent from SL that would be really handy. Some of which are considered default in every 3D modeller, and others would be well suited to an in-world editor like SL. Others I just want.

1. Camera controls: I want to be able to move the camera without losing the object I am editing or moving my Avatar's body
   
2. Orthographic view: It's a huge pain trying to line up objects in perspective mode
   
3. Hidden/non-selectable objects or sub-select from selected group: I'm forever selecting trees, plus I often want to make things transparent and select what's behind them
   
4. To go with above: a list of hidden/non-selectable objects in a window allowing re-enabling/re-showing, or a "show all" or "make all selectable" button
   
5. Prim aggregation: I should be able to select two or more prims and convert them into one prim; ideally this would invoke a polygon/vertex simplification algorithm
   
6. Arbitrary prim creation: I want to make things one triangle/rectangle at a time! Put a poly vertex limit if you must, but if I can have a cylinder with heaps of polys I should be able to have an arbitrarily shaped prim with equal number of polygons.
   
7. (new) More prims: if I can't have arbitrary prims, I plead for thirty or forty more pre-installed prims: E, L, M, and T-shapes (heck, the whole alphabet is good for construction , dumbbells, arches, windows, and more. If they can make trees, why not a collection of basic components? Please, oh please.
   
8. Offline editor: No reason that I can see that I can't have an edit object mode when I'm not connected to SL servers. Objects created offline can just be added to inventory. You've got the entire software suite already installed, why do I need the CPU-eating simulation going on at the same time?
   
9. (new) Position by corners/edges! This is an awesome feature of a few desktop pub apps, and Adobe Illustrator -- a little diagram with various buttons to pick the position. Harder in 3D, though -- easier to allow direct placement of the position indicator, and it would have to have snap, so may as well just use a vertex selection tool.
   
10. (new) Vertex selection tool .
    

Finally I STRONGLY urge the tool developers (and everyone else) to check out the program SketchUp from @last software. This is the coolest 3D design tool ever -- it's approach to modelling is very fast and accurate and intuitive and would work great in SL, way better than the "brush" (prim) approach that seems to be inherited from Quake level editors.

Then again, I like working with prims as building blocks -- don't take that away or anything. But SketchUp's tools are so fast it's almost redundant. They might not work as well in a running simulation but they would work amazing in an offline editor.

The "component" concept in SketchUp is basically what I want for making complex prims, although you'd want to go one step further and actually dump all redundant polys and actually make one new prim with the result. Ideally the original prims would be preserved and I could just keep them in my inventory. When I want to edit, I just edit the component in the offline editor until I like it and then export the optimized complex prim into SL or something.

The prim limit is a real pain. I want to see script complexity, object complexity, and geometry complexity treated separately so that I can maximize what matters to me. I should be able to trade scripting power for more polygons, for example, or vice versa. Thanks.

SL's prims aren't brushes. I wish they were! They're pre-made parametric models. Brush geometry is vertex-based. SL's "prims" send scale, position and rotation information: three vectors, then a few floats and integers to determine hollow, twist, etc. Compare this with a brush-based cube, where you have a total of eight vectors, one for each vertex. Even with good compression, it's not really possible for brush-based geometry to be as bandwidth-efficient as parametric models.

(Obviously, textures and audio clips are the worst bandwidth hogs, but object geometry doesn't help things.)

Now, I've used Sketchup, and it's a lot of fun. If I were to suggest a direction to look at when creating a new low-bandwidth (in theory) modelling system, I'd definitely have to recommend something like that over brushes. It's basically CSG tools and nothing else. You could do quite a bit with it by only sending the steps used to arrive at the finished model, not the model itself.

The CTRL and ALT keys are your friend.

ALT + mouse == zoom in and out.
CTRL+ALT+mouse == swing camera.

Once you have the camera placed the way you want, release the CTRL+ALT keys.

(I might be wrong about the keys since they've become second nature to me, but basically you can do this.)

Also, Tcoz Bach (?) posted a whole thing about hotkeys you can use too. IIRC, what he said:

CTRL+3 == Edit
CTRL+4 == Create
CTRL+5 == Land

I don't remember exactly what CTRL+1 and 2 do, but they map to the first two buttons on the Edit dialog box.

So.

What you do (again, per Tcoz):

- Line up camera.
- Release camera keys.
- Do NOT click mouse.
- Hit CTRL+3 or 4, depending on what you want to do.
- Once the menu is open, you can select and edit the object without losing the camera lock.


If you want to see the entirety of his post (which is a lot more detailed than this one, do a forum search. I encourage you to -- it's a great post)



- Er... don't you use the grid and snap-to-grid? I don't remember where the option for that is, but it exists.

- Or copy and paste the XYZ coords of the objects as needed. That's what I do mostly. I'm not a heavy duty builder like some *coughcoughLordflycoughMaxxcough* people.



- Swing the camera up overhead and looking straight down, that helps with the tree problem some.
- Hold down CTRL, click and drag to select a whole rectangle
- Keep holding down CTRL and deselect any stray objects you don't want.

(again, I may be slightly misremembering due to lack of caffeination, but that's the basic idea)

I'll let others comment on your suggestions re: the actual engine.

Sorry, I realized I only replied to a single point. Oops.

The camera controls do take some getting used to, and you'll definitely want to use the key commands for that. Ctrl, alt and shift are the keys you'll want to learn to use while clicking.

An orthographic viewer would take some doing. I don't think we're likely to ever see something like that in SL.

You can select objects behind trees in 1.3. It's about time!

A list of objects you own or can edit in the vicinity would definitely be handy. However, it's more likely that the Lindens will just let someone else figure out a way to implement this in LSL in the event we get a customizable UI.

Prim aggregation, CSG subtraction and per-face modelling are unlikely to show up any time soon, because, as I stated above, SL uses parametric models, not brush geometry.

As for an offline editor, this has come up several times, and the answer every time has has been a resounding "no". The Lindens want us logged in, not off doing our own things.

Thanks for the words about prims vs brushes.

I personally have no worries about bandwidth, having a 4Mbit DSL connection. I care about having more polygons. Waay more. We should have a polygon budget of around 10k per 1/128 land parcel. It's not that I want to have hundreds of prims -- I don't. I want to have fancier prims. I mean, I want to make my own prims.

I want to take existing prims, mutilate and link them, save them as a group in my inventory, and then "compile" them together into a new, single prim. I can understand keeping separate prims for parts of objects with joints, but there has to be a way to squeeze more polygons out of the system without harming performance by optimizing using processes.

I will have to do some pretty insane contortions to make a nice cabin on my 512 parcel with its absurdly small limit. Even the "basic chair" is 11 prims. It should be one. Or they need a more basic chair!

<homer>
Nested-links and CSG....
<drool/>
</homer>

Nergal, thanks for the info. I do try to adapt as best I can, as we all do. I'm just saying, "Hey, there's better ways, why don't we use them instead of adapting to inferior ways?"

Camera control is the least problematic, but you're right, I can do what I have to do. It just feels clumsy.

I don't use snap to grid because I don't trust the grid. What if I don't want to align to the grid, or my objects aren't multiples of the grid? Grid snapping is something I've never found useful unless it was in a Quake 1 editor where the grid was big and boxy and everything looked ... big and boxy.

The tools as is seem comprehensive, just not optimized.

Thanks.

CSG models take a lot more space to store and a lot more bandwidth to transmit. They eat more RAM client-side as well. The prim limit is set where it is because each simulator only has so much CPU and RAM to play with. Bandwidth costs money too.

I think what you want is possible, but not anytime soon. Maybe in SL 2.0, if/when such a thing might be available. Parametric deformation modelling (as Catherine suggested, and which is used by Farb-Rausch and others) might be a little easier on the bandwidth. The Product and poemtoahorse (Farb-Rausch productions) demonstrate pretty conclusively that you can do extremely slick stuff with this technology within an extremely tight memory space.

However, parametric deformation modelling is more CPU-intensive than the regular parametric system we have now, so again it's one of those "maybe we wait a year or two for more people to get faster machines" situations.

Instead of completely revising the current modelling system to use CSG or something else equally different and complicated and resource-intensive, can't they just extend the primitive system a little bit?

Do all the primitives have to be concave? Or is there some other limiter, say, because of their mathematic representation? Are they, for example (checking Computer Graphics text...) superquadrics or some other standard type? Or are they just a somewhat arbitrary set of shapes of maximal usefulness stored locally?

Catherine says that the prims are parametric. Is that accurate? I mean, are the geometric shapes formed form parametric equations? I would have guessed that they are simple bunches of polygons. The transformations she mentions are applied to those polygons, just like in most 3D games. What makes a set of polygons a prim is the addition of transformations, textures, and scriptability and ownership information.

Anyway, that's how I'd like it to be, because if so, it would be easy to have convex, irregular shaped prims. It would just require either a bunch of more interesting prims to be provided, or a way to let builders merge existing prims and run a simplification algorithm to take away redundant faces and vertices. If it used CSG to perform the simplification, so much the better, but I wouldn't expect live CSG-based models directly in-game.

You can have both concave and convex models in SL. They're called parametric because the way it works is something like, "okay, here's a box. But cut it in half. And then hollow it by 30%." It's pretty simple.

Remember, "prims" in SL aren't primitives in the traditional computer graphics sense, they're fairly detailed deformable models. We only call them prims because that's what they look like. If the Lindens wanted to implement a Statue of Liberty "primitive", there's nothing stopping them. The trees and grass objects are also considered "prims".

The reason the upgrade of the Havok physics engine from 1.* to 2.* has taken so long is because concave bounding functionality was dropped in 2.0, but is back on track for 2.2. (Version numbers are approximate.)

I would DEFINATELY love this feature, as with most 3D modellers out there, I guess its similar to the add/subtract/union commands found in most 3D modelling programs.

Personally I enjoy creating vehicles with great detail, whether its the suspension/dash in cars to the landing gears/vents of aviation aircraft. The only problem is that I CAN'T PILOT THEM when THEY ARE FINISHED... then I would have to strip it down to the poly limit, (thus making it look like some basic shitty toy-like vehicle) before I could even do anything.

This is a serious limitation on creativity, to mention towards the in-game object creation capabilities.

Taking for example, a car body with all the fixtures & trims may take up like say, 50-80 prims? However, since its a fixed ridged body, its no point letting the engine do physics calculation for each of the individual prims. Therefore, the "MERGE MESH COMMAND" will more or less, as the name suggest recalculates & merge all the selected prims permanently into ONE prim, thus not only allowing us to keep the vehicle prim limit at 32 but only requires the system to do a physics calculation of only ONE OBJECT.

This too is more or less a way to get over the physics lag issue, inevitably faced with increasing the vehicle prim count limit. This is a serious option. Please include this modelling option in the upcoming revision of SL. In the name for all builders/modellers out there please.

Thank you