Cubes with curved edges

*Prepares to be yelled at*

I think I've seen this asked somewhere else but I've spent the last half hour searching the forums and can't find a post to bump

I've started building a lot of furniture again and it would help soooo much.. Look at the picture, with curved edges that could be achieved with just 6 prims (and without the gaps).. As it is it takes up a massive.. wait for it... ready?? 54! 9 times as many...

I don't know if Havok 2 will bring in new prim shapes or make it easier to create new prim shapes, or if any new prim shapes are in the works.. I remember a town hall with Philip ages ago something asking, and him saying some new prim shapes would be cool but there weren't any plans for them..

Ok you can yell at me for bringing something thats already been asked up again now

Edit: Ooops didn't mean it to be huge, how did I do that?

From my response, here...

Because this has been requested a couple hundred times, let me start by saying that this is, by far, the most popular feature request I have ever seen on these boards.

So, let me quote myself on how it could be done.

Is this why we've now got rounded progress bars, rounded tooltips, rounded chat balloons, rounded *#&$*# name balloons... but still no rounded prims? For pity's sake, set a minimum face size or whatever they normally do with rounded objects like cylinders and elliptoids and be done with it!

Jeffrey, have you ever considered becoming a Linden? Can we start a grassroots campaign to make you one?

neko

*Seconds Jeffery should be a Linden*

Sorry! But I really did search the forums, I was searching for curved rather than rounded.. But I would have ended up bumping one of those if I found it hehehe..

I don't think I've seen anything possible thats been requested this many times and not done.. So pleeeeeeeeeeeeeease!!!! lol...

Zap

I think its because mainly the reason for the 'rounded prim' phenomina is that when some things can be created to be accurrate (like homes for example). Those items are mainly used for squarish objects.

The world isn't square, so I think it lays within being a perfectionist. For example, if I wanted to model futuristic car (we can expect those to be well rounded). How can we make them look accurrate with squared prims? Or if I wanted to make an accurrate model of the B-2 Spirit Bomber (which I've been trying for ages now), how would I beable to do it within the prim limitations without having rounded prims?

Of course there would need to be an overhaul of the code I think in order for this to happen, but I think its possible.

I don't know if they'd need to edit a huge amount of code to make it possible.. I can't believe they brought in the ring before they looked at rounded corners..

I would also like to see this. It would be cool as a slider / value with a range of 0% to 100%. The way I would see if working is like this...

Let's take a cube for instance. (See image below as an example of a cubes face with various values.)

1. A roundness of 0% would be a standard cube.
   
2. A roundness of 50% would have each edge rounded such that 50% of a face along any given axis would be flat.
   
3. A roundness of 100% would essentially make the cube into a sphere.
   

I'm not sure if I described that clearly, but it's ideally how I would like to see it implemented. Obviously other prims could benefit as well, such as rounding the ends of cylinders. I can see the potential problems with added polys, but the physics engine would still use the standard bounding boxes to calculate collisions.

McW

McWheelie: That's a subdivision algorithm as I described, or else it's a very neat NURBs trick. I think we're all on the same page here... it's just, well... needs to get forwarded on up!

And I'm not a Linden purely because I live at the other end of the US, not because I don't want to be. I've considered applying for CSR... but I don't feel it'd benefit the community much if I had to guard my opinions and advice because I were connected with the company.

Well said all!!

Attention Lindens! We need attention!! lol...

At least reply and tell us if its possible, or whether it will be with Havok 2..

Thanks for being gentle on me. I am not as well versed on the 3D algorithms and terminology. I do try to learn more each day though. Seems like the list of things I want to read up on and learn more about is expanding geometrically though.



While living across country could be worked around with some high-speed VPN magic, I agree that CSR probably wouldn't be the best use of your talents. I want to take a moment, and thank you for all of the amazing scripts and ideas you have been contributing to the community.

At any rate, what we should really do is create an NPC Linden using the model importer and bvh importer. Then have them add the rounding feature to the list in a semi-reasonable slot.

McW

This discussion thread has been linked to Prop #49, but I'd like to suggest that it also be merged with Prop #202, provided the additional detail from Prop 202 be included:



Just wanted to try to tie the props together so the votes could be accumulated correctly.

neko

*BUMP*

Vote for Proposal 49!

I've got all 10 votes assigned to this!

Zap

There is an alternative proposition that can achieve the same thing (and quite a lot more too). It considers performing boolean operations on primitives.

To keep prim count reasonable, (in contrast to the proposal below) you still count all prims, both negative and positive (some prims might be negative, i.e. removal prims that display as a hole in another prim). But the technique still allows effects to be achieved that would require a lot more prims otherwise. An example is the discussed "rounded" corners. Simply take a box and delete from it the inverse of a ball that doesn't quite contain the box. That would effectlively create a box with rounded corners in two prims: a box and a ball.

Prop: 138
Name: Boolean operations on prims in editor
Category: building
Subcategory: editor functions
Author: Monique DeFarge
Prop Date: 2005-04-14

Feature Detail

Make a possibility like in other external 3D editors like 3D tudio max or Truepscae to work with boolean operations between single prims, like substract or add to created higher detailed single prims to reduce the need of using masses of prims to create better looking detailed objects. For example lets just say take an simmple cube, place a sphere partially in it, then substract the sphere from the cube (or vice versa), or add both objects into a simple prim by melting them, and cut off the unneeded parts. Or just imagine creating a colum with some parts, looking detailed without the use of xx prims on it, just 'melt' the different used parts into one single prim then.

Alhelor,

First, boolean prims are hard, as Cory said in the town hall the other night, and I wouldn't expect them anytime soon.

Second, what you described wouldn't make a shape like what Zapoteth showed us at the beginning of this thread (though it would make a different, also interesting shape). To make what Zapoteth showed us, you'd need nearly as many prims, I think. Maybe 7 instead of 9 per cushion shape, if you used cylinders to round the edges, possibly as few as 4 if you could use an oblate sphereoid to get the corners, but I'm not at all confident it would look right. Diagonal thin spheroids for the corners might get you to 5 prims per cushion, still too many IMHO.

Then again, I don't have a tool that does this to experiment with. If you have such a tool and you can post an example of a shape like one of Zapoteth's cushions and say how you made it with 2 prims and boolean interactions, that would be helpful.

'Till then, I'm leaving my support on this proposal.

neko

Hmmm, sorry people, didn't look at that picture before posting Anyhow, I still feel boolean operations on prims would be really cool! There are loads of things that could be done with them, even if quickly getting that exact cushion shape isn't among them. As to difficulty of implementation, that is entirely dependent on the internals of SL. If Cory says it's hard, well then I suppose it is

Today I was looking at picture of dice, trying not to think about my gambling addiction.

And then it dawned on me, that most dice do in fact have lovely curved edges which make them a joy for the fingers to hold, as opposed to saw-juttiness and a harsher veneer.

This suddenly made many dice as I've seen them in SL, represented as 1-prim cubes, look very very wrong.

Yuhuh! lol... Although its not the first thing that crossed my mind when I thought about curved edges..

We neeeeeeed them!

I hope it wouldn't stop at just curved cubes. It just seems like this feature would be too little too late. Technology like that of Will Wrights "Spore" should be the focus for the next gen Second Life graphics and design engine. Where objects and certain textures are generated procedurally using algorithms rather than a few prim settings.

The benefit of current tech is small data streams with all the descriptions of the prims and connections that make an object that the clients graphics engine can then display. Will Wright has mentioned that the compression factor on Spore's complex code generated creatures is very compact and easily transported over networks. I'm sure our SL objects can do without the more complex data in Spore creatures making the bandwidth needed similar to what it is now. There is only a visual need ( no DNA, memories/AI, or needless simulation data ) so this should work well.

Am I alone in thinking that the graphics and development engine of Second Life won't be easily expanded to add more flexibility and power without a complete overhaul?

I hope it wouldn't stop at just curved cubes. It just seems like this feature would be too little too late. Technology like that of Will Wrights "Spore" should be the focus for the next gen Second Life graphics and design engine. Where objects and certain textures are generated procedurally using algorithms rather than a few prim settings.

The benefit of current tech is small data streams with all the descriptions of the prims and connections that make an object that the clients graphics engine can then display. Will Wright has mentioned that the compression factor on Spore's complex code generated creatures is very compact and easily transported over networks. I'm sure our SL objects can do without the more complex data in Spore creatures making the bandwidth needed similar to what it is now. There is only a visual need ( no DNA, memories/AI, or needless simulation data ) so this should work well.

Am I alone in thinking that the graphics and development engine of Second Life won't be easily expanded to add more flexibility and power without a complete overhaul?

"Am I alone in thinking that the graphics and development engine of Second Life won't be easily expanded to add more flexibility and power without a complete overhaul?"

i don't believe it's just an issue of implementing new features. for example, the benefit of going to a procedural material system is greater quality and variety at reduced bandwidth. so does LL dump scanned/uploaded textures? would SL businesses based on scanned textures appreciate this? textures are the bandwidth hog afaik. not prims. now if we could eliminate uploaded textures we'd need some way to do logos and such still, correct? i can't do logos in Maya with it's materials editor, for example. LL could use vector graphics (SVG?). they're efficient. but if someone wants, say a t-shirt with a logo on it, they'd likely have to integrate the two: the vector graphics and the materials system. which means that SL would have two new and possibly complex tools to learn.

and what about those SL clothing businesses? some have scanned repeatable fabric patterns. do they now have to go and make vector graphic files? and also materials? ouch. and how would the consumers feel if their inventory was made obsolete? furthermore, should the changeover happen immediately? if so wouldn't that effectively level that market? is that fair to established businesses? and if it occurs over a transition period, couldn't that put a bigger strain on SL - having to deal with both large texture files and vector graphics and procedurals?

meanwhile, it seems as if prims are held hostage to texture bandwidth issues. i've read that land prim limits are aimed at limiting textures - not geometry. so even if LL wanted to expand prims and introduce more complex geometry, wouldn't that exacerbate the texture issues?

and fwiw, rounded corners are a continuing issue in even highend 3D apps. it's not a simple issue. and i would expect it to be addressed after textures/materials are resolved. i don't like it either, but given all the possible ramifications noted above, i understand. this isn't just about the technology and the code.

I know it isn't just as easy as adding new features. Once you build an engine, if you didn't intend for something to be plugged in, it's not going to without an overhaul. Now given SL developers are smart and maybe made modular code this shouldn't be too much of a problem, except that it is. Probably too little staff or not enough time to dream about things.

I do not see why the two cannot exist parallel. I'm thinking more of procedural objects than procedural textures and what you see in Will Wrights GDC demo is NOT exactly what I am thinking of since it includes creatures as well as buildings that are built upon this procedural method.

It's never really a matter of technology or code but the imagination and intuitive ability behind it. Lazyness and deadlines tend to foul that up. How modular Second Life's source is developed decides the ease of simply adding a feature.

Imagine the furniture possibilities... mmm...

It is important to clearly distinguish between prim count (which everyone here seems to be talking about) and polygon count (as mentioned in the Linden comments, and the thing that actually effects performance and lag.

Prim Count is really irrelevant. The only affect that allowing corners on cubes, or curved edges generally, has is it reduces the number of prims you need to get specific shapes. But parcels still have the same prim limits.

Polygon Count: this affects performance in at least two ways:
- rendering: could be done at the client level (like animated textures) and hence involve no server cpu time or network costs (except for the extra parameter of "amount of curved edge: 0-100%" on the prim itself). it still of course effects client performance. But think about it: 1 prim cubes have 6 polygons, 1 prim spheres have potentially hundreds of polygons! Same with toruses. And even rings and cylinders and cones have lots. This will not seriously affect lag on the client - its will only have an effect of a few percent, and people can just move their Object detail slider down a fraction to compensate if they want.

- collision detection: using bounding boxes (i.e. same as the original prim with rounded corners) rather than the actual prim would incur no extra penalty on the engine or the network. For many prims that have < 50% rounding this would hardly be noticeable. For the others, well, maybe you need to use extra prims. Tough.

Is summary, sounds like a great idea to me. Just do it.