the Plane

I want to make a proposal to edit the modeling system in SL

I propose the addition of a polygonal face otherwise known as a Plane. In most standard 3d Programs users have the ability to work on their objects at the level of individual faces and beyond. The point is that editing on the level of faces makes things much easier to manipulate rather than having a million prims in one place to confuse you.

By nature they are one sided but usually render on both sides which makes it easier to texture something that has the same image on both sides such as a window or logos ect ect.

A Prim is made up of several faces there is no exception (in SL), a cube is the best example, on a default cube there are 6 faces and in some cases when you use them anywhere from 2-4 faces could be hidden at any given time wasting your computers processing power with each face that hidden because they are still being rendered.

With the use of faces users could model things more effectively, as I just said many faces are hidden even when your trying to make something as simple as a noes or lips. You could make those details very fast with less a few faces rather than 2-3 prims you won’t see 90% of.

The use of a face prim could also pave the way for a possible exporter in popular programs such as Blender, G-Max, Maya PLE or SoftImage XSI (because they are free to the public). Such exporters already exists in the community but use Prims in such a way that they become very less effective because of the hidden face problem I mentioned above.

the addition of this feature would save the development staff a lot on resources if the need for an external modeler ever arose since there are already plentiful alternatives to it.

I also raise this proposal as a complaint, those of us who have experience in the programs I mentioned and their professional counterparts have experience that completely contradicts the modeling method of SL but it none the less the methods are still very much part of the processes. Being that in alternative programs you can be several times more accurate with models it makes if very frustrating to adapt.

I totally agree, though it would increase lag alot and totally destroy the use of prim counts.

well in the respect of Pim count yes i would but in respect to that the face count would be lowered signifigantly. if people could model with planes in combinations with boxes we would have far simpiler architecture that would render faster and run less of a risk for texture errors (such as when a wall is overlapping another with the same texture and it flickers) if the ability was there to line up planes for a long span of wall you would reduce general useage errors.

What should a "plane" object look like to the physics engine?

A very thin cube, I would think.
Either that or a planer deflector (OMG! Those exist? Yes they do, they are called "planer deflectors"

If this is geometrically like a cube, then I'm not sure what advantage this would have over a non-physical or thin cube with all but one face set to an Alpha of zero. Zero-alpha faces don't even show loading textures, and it would be easier for LL to remove them from the render mesh (if they don't already... remember, you can't even click on a prim with an alpha of zero except in the editor) than to create a new prim type.

The advantage is prim count. I would think that a plane (say having only one renderable face) would be worth 1/4 or 1/6th of a prim (seeing as there are 6 of them on a cube).
The physics geometry would be no different if everything is done with cubes anyway (as we all know, Havok 1 sucks).

The cost to the physics engine would be the same, and the cost of a textured face is not likely to be significantly less than the cost of a typical textured cube, since a single textured face would likely be a high quality texture anyway.

And if you're going to assign costs right, a hollow cube should cost like 2 or 3 cubes, and a torus should cost like 4 or 5, and a twisted truncated dimpled hollow torus should cost 20...

Fix the stuff that matters. Saving cube faces doesn't matter. Charging the same for a 3000-vertex monster that requires 40 bounding boxes for the physics engine to handle collisions for and a cube... that matters.

Argent, I am getting tired of your dictatorial notion of what matters in SL's development. SL's framerate is ATROCIOUS--even with LOD and local lighting OFF. SL has so many wasted/covered/hidden polygons it's pathetic. Part of that is just bad modelling but most of it is due to SL's mindless "brute-force" rendering where it doesn't even TRY to cull hidden faces. That's just pathetic.

A plane "prim" type would help, but SL also needs the ability to set ANY prim's side to be non-renderable.

http://tnlc.com/eep/sl/index.html#building

What, even when I back them up with numbers?
And a "plane" prim would make negligable difference to this.

A cube has 6 faces, 12 polygons. A plane prim would save 10 polygons in a one-sided sign. A mall wall with 50 signs would save 500 polygons. A single twisted truncated torus anywhere in LOD has more polygons than that.

Also, you can stretch a cube so that three square faces are visible and to the limits of rendering in the same plane, allowing you to display three signs on a single prim. In that case the plane prim would only save half the polygons of a cube prim.
They have it. It's called "setting the alpha value to zero".

I don't know if they are making good use of this information, but the client really doesn't seem to really know about the presence of 100% alpha objects that aren't owned by you until you turn on rendering for them with "show transparent", so they may be. In any case:

1. If they aren't then doing so would save orders of magnitude more polygons than a plane prim.

2. If they are, then there's no difference between a plane prim and a cube with 5 sides set to zero alpha. None.

And what about all the sides on a torus/sphere that you can't hide, but cover up with another prim?as far as I know, you can't set the alpha accurately enough.

I asked about this recently and apparently they are rendered. Although the answer was from Torley and seemed to be based on the fact that you can see them with show transparent, so it could be wrong.

Just wondering how you came to the conclusion that the client doesn't know about them?

That depends on how they implement "show transparent".
I think I phrased that badly. What I mean is that the client doesn't seem to include them in calculations that it does include things like almost-zero-alpha prims and invisiprims in, like touching and selecting for edit, and they don't show up during loading like 100% transparent textures do.

The point is that it'd be possible to get the same win you get from this "plane" object by having the client be sufficiently clever about how it deals with 100% transparent prim faces... and without creating more user-visible complexity.

That's why it really does help to cut your rounded objects to flat surfaces where you can't see them.

Cool. Thanks for the clarification.

I agree that implimenting a new prim to save 10 triangles a copy totally isn't worth it and would have a negligable effect on framerate. I'd like to see different values for different prims though (as I've gone into at length before).

Guess while I'm here I'll comment on some bits of the thread before I get back to work. I'm kinda rushing, so please excuse the fact that I'm not quoting what I'm refering to. It's all in chronological order though, so it should be easy enough to follow.

I don't understand why this request is for a plane prim rather than a triangle one which would make more sense for what I'm understanding the OP is saying.

Building a polygon model using the prim system is counter productive. The prim system is in place to allow models to be streamed easily. Making a polygon model out of these suggested prims would be heavier on the bandwidth than sending the original model.

Philip has said that he polygon models will be needed in SL in the future, it's just the networking technology isn't up to it yet.

I've heard several talented modellers say that modeling in SL has improved their modeling in standard 3D programs quite a lot.

Flashing walls are due to either the alpha sorting bug or bad construction. New prims would solve neither of these problems.

Oh yes, me too.

I'd like to at least be able to toggle between "twist" and "bend". Just being able to do a few degree bend in a long prim would make a big difference to large builds.

I'm really surprised there isn't a bend modifier already, it's a pretty basic thing to want to do really. I'll add it to billboarding on my list of things to make votes for when I get 'round to it.

That you pull out of your ass? So what?

Every polygon helps reduce framerate; they all add up. This goes back to that efficiency thing we're discussing in another thread. It's all relative. Please, learn to think relatively...

Yes, in THAT case, but how many people are going to do that? Not many. Glad to see you CAN think relatively though...

Um, no. That still renders it. Try setting a few (like 20) twisted, hollowed torii like that and let me know how your framerate is. Please, Argent, at least get your facts before replying next time.

See above. Alpha doesn't affect rendering.

No need to be so moody Eep - they're introducing occlusion culling soon!

I get moody around stupidity and ineptitude... I'll believe occlusion culling when I see (or not) it.

That explains a lot. If things go to plan I believe it's due by the end of the month, it's part of 1.9.1 and their already running the preview internally if I understood Philip correctly.

Yea, lots of stupid/inept people in the world.

<waiting on the edge of my seat--no, really...>

There's a limit though.
For one avatar I own (a raptor) there are a number of impossible cuts that could reduce poly usage, but in so making the cut just slightly more a portion of the visable prim disapears.

the number of polys in a cube isn't "pulled out of my ass".
And if development time was free all possible approaches to reducing polygon counts would be equivalent. Since it isn't, it's vital to consider the costs and benefits of competing optimizations. So, there's three optimizations to be compared:

1. Plane object.
   
2. Flattened cubes.
   
3. Culling 100% alpha surfaces.
   

A lot of people do. It's a standard building tool these days to reduce prim counts, and there's people using hollowed sliced cubes to get 5 "plane" textures from a single prim.
I didn't say "this optimization is implemented", I said "this optimization is possible"... and by making that optimization Linden Labs can get a MUCH bigger win than a "plane" object for a lot less cost... and you get the plane as well.

1. Plane object: reduce poly counts by a factor of 6 for signs, and by 3 for walls, but doubling the prim count for walls. Maximum potential savings, 10 polys per visible surface.
   
2. Flattened cubes: reduce poly counts by a factor of 2 for some signs and walls, and reducing the prim counts for some walls. Maximum potential savings, 4 polys per visible surface.
   
3. Culling 100% alpha surfaces: reduce poly count by a factor of 2-6 for any object where one or more surfaces is known to be completely obscured. Maximum potential savings, unbounded... may be hundreds of polys per surface for some objects.
   

Understood. That's where the tradeoff between computer efficioency and human time comes in.