[#VWR-3853] Geodesic prims (including Dodecahedron and Truncated Icosahedron as explicit cases)

1. Second Life Viewer - VWR

Geodesic prims (including Dodecahedron and Truncated Icosahedron as explicit cases)

Created: 15/Dec/07 08:34 PM Updated: 28/Feb/08 06:03 AM

Return to search

Component/s:

Building (in-world)

Affects Version/s:

None

Fix Version/s:

None

Issue Links:

Relates

This issue is related to by:

VWR-5189 Allow sculpties to be edge stitched to each other in a linkset (Sculpted Prims)

VWR-3852 Meta-issue: Prim-shape related stuff

Description

« Hide

Why not

I have actually had want for these at times and needed to resort to manually constructing them from a ridiculously large number of prims!

Set the number of faces and use a standard geodesic algorithm to calculate the shape for general geodesics, including the Icosahedron (20 sides). Use invalid #_of_faces values to flag Dodecahedron (12 pentagonal sides), and Truncated Icosahedron (soccer ball - 32 sides, 12 pentagon, 20 hexagon) shapes as special cases.

Would be treated like spheres in the editor, with dimple and cut rounded to take out whole faces at a time?

Probably treat as faceted spheres in the Physics engine too.

All

Comments

Change History

Sort Order:

[ Permlink | « Hide ]

WarKirby Magojiro added a comment - 16/Dec/07 10:29 PM

why not use sculpted prims ?

[ Permlink | « Hide ]

LaeMi Qian added a comment - 17/Dec/07 12:22 PM

AGAIN with the sculpties-as-be-all-answer ;-D

Actually, sculpties are a pretty good way to do this - event he spherical physical presence matches well. However, sculpties cannot be hollow, cut or dimpled ATM, and also, native shapes would use 12/20 planes versus the 1024-odd of a sculptie. And sculpties are meant for organic shapes, and as such tend to get rather ill-defined on sharp edges, unless you overload the verticies which still can be messy.

I realise this is not something that would see as much use as cube/sphere/cylinder, which is why I set it to lowest priority available, but mathematically-defined shapes are always WAY more efficient and neat than free-form ones. I wouldn't expect this to be implemented on its own, but if the prim system was getting an overhaul (it is close to needing one, I feel), I would like to see these thrown into spare shape-def slots.

[ Permlink | « Hide ]

LaeMi Qian added a comment - 17/Dec/07 12:34 PM

I changed the topic as I realised a more generic shape-type that covers both cases and more, which is always a better solution!