Mini-Essay on Sculpties and their Limitations

Hi guys

Luca, Neil and me wrote a little essay on why sculpties aren't good enough.

Please comment

http://morbo.cs.pdx.edu/sl/sculpties.pdf

Note: This essay does not cover implementation flaws, such as the one Cottonteil details here:
http://forums.secondlife.com/showthread.php?t=186732


Thread mirror on secondcitizen:
http://forums.secondcitizen.com/showthread.php?p=428342#post428342

Edit:
Clarification - we are talking about input formats into SL, not streaming formats out of SL. More details on this point here:
http://forums.secondlife.com/showpost.php?p=1672935&postcount=7

I support and/or endorse this product/feature.

hehe. Good god yes whodoIhavetokillormaimforthis please!

We just tried to build a car for Peugeot. Spent a week trying to make sculpties work for ANY part of it. The front seats are sculpties, and they're only saved by the fact that they're enclosed in the car which makes the lumpyness less visible.

We don't want this, we NEED this.

We know the arguments for this low detailed compromise, but damnit, we have to hack at it enough to eliminate all the possible benifits of the current approach to produce anything useful.

Scuplts suck. For the reason listed above.

They are next to useless for clean edged models. They do, however, make fine bananas if you don't look too close.

The worst part in my eyes it the waste....1024 verts, all those polys to draw...LL argue that it's no more of a hit then a torus...well, torus is a big hit. Thank god for flexi prims limits that do not allow torii 'cause now i can look at people's heads without lagging to death.

SL is lag pit. Sculpts contribute to this greatly from their limited and skanky design.

I could go on, but why?

Firstly, I'd like to get this out of the way first, I do not want this thread to fall into a petty argument and/or flamewar. That being said, i'll try to reply to this with as much civility as possible.

Your discussion of sculpties vs. arbitrary (non-procedural) meshes is missing two critical components:

Streaming: Everything in SL obviously streams. The beauty of having a mesh that is always constructed of a uniform quad-patch is that as said object streams in, it progressively loads and accrues detail. If we were using something akin to an .obj (which must totally load before it can be added to the draw list) objects would 'pop' into existence once they were fully loaded. The difference in akin to having textures be jpeg2000 vs. a format that can't progressively load (tga for example).

LOD: If you pull up most any video game that deals with large amount of content on screen, you'll notice that assets have multiple versions based upon their distance to the viewer. This obviously is for performance-sake. Objects close up will be drawn at full detail whereas objects far away will be drawn using a much simpler mesh. For this to be accomplished, multiple version of every asset must be made manually. The beauty of a sculpt map is that LOD can be done procedurally, by constructing the mesh out of every other row of pixels (16x16) every fourth (8x or every 8th (4x4). This makes possible the ability to make custom meshes without having to manually create different version for LOD.

As for cottontiel's arguments regarding sculpt bumpiness, those are now moot now that there are several ways to losslessly upload sculpt textures (libsl, rcviewer). If your model is made properly now, there is no reason that a perfectly smooth and flat surface should not result once converted to a sculpt map.

Yes, using sculpties is difficult. Yes, a paradigm of modelling has to be used than that familiar to many poly-modellers. Yes, there are frustrating limitations and control over normals, mesh distribution and custom UV maps would be nifty. But outright dismissing the technology (one which might i say is a brilliant mid-ground between streaming, optimized 3d data and possible detail) is irresponsible and immature.

Good, detailed analysis... but I thnk I disagree with your underlying thesis. The thing is, you're writing this as if sculpties were designed to make detailed, precision meshes, and that's not what the system was made for. Sculpties were designed for handling approximate, organic (ie lumpy, not pointy) shapes in SL while still keeping the size of data travelling down the wire small and working with the existing LSL system. This is fairly incompatible with doing precision meshes like those cars. It's not that the tool was poorly designed... it's that it was designed with different goals in mind than you're evaluating.

Edit: oop, Xenius beat me to it with a far more detailed argument.

In that case I still want what francis is suggesting for my goals . Something designed for my goals could incidentally also still work for theirs. The reverse is not true.

Some counter-points:
- I am saying that .OBJ should be used as a format to *import* into SL, not to stream from SL to client. There are many different solutions for streaming arbitrary meshes that are outside the scope of this discussion.

- Just as there are many solutions for streaming arbitrary meshes, there are ways to run LOD refinement on arbitrary meshes. I believe they are also outside the scope of this discussion.

For more information on the last two points, these guys are really big in this area:
http://www.cs.unc.edu/~isenburg/sm/
http://www.cc.gatech.edu/~lindstro/
http://research.microsoft.com/~hoppe/

- I disagree that arbitrary meshes are at odds with fast "handling approximate, organic (ie lumpy, not pointy) shapes in SL". I am trying to emhasize that we can do more with less. If we have *better* vertices, we wouldn't need so *many* of them. If we had better UV mapping, we wouldn't need such big textures to cover them with. I think goals of "good vertices" and "good streaming" are not mutually exclusive.

- "objects would 'pop' into existence once they were fully loaded" - This is not far from the current state of the system. If you fly across mainland, you would indeed encounter popping artifacts. You can, however, get things to progressively render using aformentioned streaming solutions.

OK, your sculpty car uses ~30,000 verts, and CAN be made with <5000
BUT...
How does LL constrain the use of text(obj) files Size < 15000 *32*32 ?

Prim use in the first place and prim allocations is ALL about constraining the number of verts to a level that would (in theory) not overburden the transmisions.

If it seems to you that an entirly mesh based protocal would run faster or more efficiently, then concider the same with many people abusing reasonable limits with reckless abandon.
Then ask if there's some way to impose reasonable limits. If you come up with a really good method I'm sure LL would be all ears. or better yet open your own sim

guys! i wish you'd come and talked to me directly - i don't bite, promise.

short answer: yes, we need true progressive meshes too. no question. and we'll have them - but hey, it's all about stability these days.

and sculpties are hardly worthless. we're just now starting to see true sculptie cool factor:

http://www.youtube.com/watch?v=3yrZl01bJOU

once we have flash-animation generated sculpties, i think i will be able to rest.


K.

I sure hope they'll be all ears.

One potential method: Let's create a new prim type, "meshprim". You can apply an .OBJ to a meshprim, much like you can apply a texture to a sculpty.

Here's the new trick though:
If you upload an .OBJ mesh with 150 vertices, it counts as 1 prim.
If you upload an .OBJ mesh with 300 vertices, that prim counts double.
If you upload an .OBJ mesh with 450 vertices, that prim counts tripple.
.. And so on.

Haha okay

We're not saying sculpties are useless - I've seen nice sculpty fruit and flowers for instance - We're saying we want the tools to be express the content we want to have.

So okay, we're in agreement that we need true progressive meshes - when?

Also, how do we reach you directly?

I could not agree more that sculpties are certainly wonderful and a big compliment to the prims. I also agree that stability is paramount, it being the largest potential time suck when building anything.

Sculpties have their place and indeed, as the video shows, can do things that imported objects could not. I certainly do not intend to demean them, or the work that went into putting them in place. I am quite happy they are there. Thank you! However, for the type of work one needs these types of tools for most often, an obj would be preferable and allow for a much broader and more inspired range of creations. There are of course other things that come up as a result of implimenting something like this, though as Francis mentioned they are outside of the scope of this discussion.

As someone who models outside of SL fairly regularly, I am constantly wishing I had the ability to export stuff to SL. I can think of a large number of items I would have had in SL could I have the ability to import objects. It would have taken me less time to create things I have created. Again, I cannot count the number of times I've said "I wish I could import a damn object, this wouldn't take me half the time" The end product would also have been of a higher quality than what I can achieve in SL now given the tools we currently have.

I am against usurping the prim and sculpty system for obj's, there are aspects to both that I really rather like and they do make building some things faster (not to mention that would be a nightmare I would not even want to comprehend). But object importing would be a hell of a great feature addition.

To further illustrate my personal point, tomorrow I have to create a sculpture of three people standing together. It has to match a real world sculpture. With obj import I could do this in no more than half an hour. With the current system, while at least I can do it, it will take me, I estimate, roughly four to five hours. The time disparity comes from the difference in process. I have to break this one sculpture into several objects and prep each one for sculpty map generation, then export and assemble it all in SL. Each object requiring a script to apply the map since I cannot upload directly a lossless map and have to apply via uuid. Placement and matching up of each piece etc. You see how complicated the setup gets and how much longer it takes. Great for a banana or apple, not so great for things of this nature, despite the organic nature of the model. Not such a bad break for me as I get paid by the hour, but it sucks for my client, making things more expensive than they ought to be.

For what it is worth, please mark me down as ultra interested in how this all plays out.

Francis, I had had a lengthy post written, defending the merits of sculpties, going into all the technical reasons I know for why sculpt maps make sense over OBJ and other text based mesh-descriptors given SL's present state of development. But then I hit the Preview Post button, and when the screen refreshed, I noticed that a ton of conversation had happened in this thread while I'd been writing, and the discussion seems to have evolved to a much better state than when it first started.

I'm pleased to see that not only have other people already said what I was going to say but with a lot less words (definitely a good thing), but also that your responses to them have been not at all what I would have expected from the paper. The ideas you posed in your "counter-points" post have me genuinely intrigued.

I think it's somewhat unfortunate that your paper didn't present itself with the same tone you've been using so well here. Frankly, it read more like an attack on sculpties than a useful showing of alternatives. If you don't mind my making a couple of suggestions, I think rewriting the paper to include the things you've talked about here would be a good idea.

For example, when I read through it the first time and got to the point where it suggested using OBJ as an import format, my immediate reaction was to think "but streaming OBJ's would be a nightmare," and I started writing down all the reasons why (for that post I was gonna write instead of this one). However, now that you've made it clear that the importation format and the streaming format could be two different things, the idea makes a lot more sense. I'm very interested to learn more about what you might have in mind.

I think if you change up the paper a bit you could turn it into a very powerful presentation which people would be much more likely to accept right off the bat than they are with it in its present form. Maybe have it talk a little bit about the good points of sculpties (fast streaming, easy LOD, etc.), and then show how your alternatives could have the same benefits.

I'd be really interested in reading the paper in a more fleshed out, less aggressive form, so as to completely understand everything you guys are trying to say. I'm betting what you've said in this thread is probably just the skin of it.

Well, my coauthors and I have different opinions on what the solution should be. What we all agree on, though, is sculpties aren't a complete solution. As for why it's written the way it is, well it's been my experience that if you say something with only positive tones, people just agree and then nothing happens.

As far as the solution goes, and progressive meshing, etc. there are many solutions that would work just fine. I don't want to waste time arguing what might be the optimal solution, I just want to say there needs to be a solution.

~~

I am sure that many people would object to it, but the following is my opinion and I recognize there are better solutions to be had. (But this would be easy to implement)

If it was me, I would just strip down the fluff out of an .obj, compress it, and send it over TCP, be done with it.
Reasoning:
- It would be easy to implement.
- It wouldn't have nice progressive rendering characteristics - but neither do sculpties or anything else in SL. Fly around, watch stuff pop into view. I think we should just throw in the towel with progressive rendering and just try and make stuff download fast.
When I drive my car at the track, I have to set my draw distance to 512m, and keep everything in view. Streaming geometry sounds like a good idea, but SL doesn't do it well.
- It would be fast to render, less lag in busy areas. Fewer polys to draw.

*hmm somehow im logged in as my wife. no matter. i have to get to werk soon. and ill be brief.

sculpties are great. i have been able to do so many things that i wouldnt have been able to do b4. what a variety of boulders and sofa. how bout shoes?!?

yea its a designers challenge some times to work with that one place that in the nurb that gets all janky. but a smart designer will be aware of that and design around it.

i seriously hope that LL avaoids doing anymore research in this paradigm b4 they re-introduce windlight and address other performance issues. those r far more imporatant things than making seats for another car commercial

what we need in the intermission between sculpties and hard line mesh is not smarter coders but smarter designers!

-shuk

nice essay btw Xenius Revere.

Something that just occured to me.

http://wiki.secondlife.com/wiki/Sculpted_Prims:_FAQ

Q. How detailed can a Sculpted Prim be?
* The current implementation samples the Sculpt Texture (or Sculpt Map) by different amounts depending on the "Level of Detail" or LOD. Prims which are close to the viewer camera have a 32 by 32 grid of vertices, which drops to 16 by 16 as the prim moves away from camera.

This means that a minimum detail sculpted prim is 16x16 = 256 vertices/prim. This is more than the numbers that's been suggested for a full-detailed meshprim. (Maybe around 180 vertices)

So an meshprim rendering with no LOD would render faster than a current sculpt-prim with no LOD.

Personally, I dont really use scupties as if they were to be exact photo realistic representations of RL things. Early on it was obvious that would be like trying to build a laptop out of rocks. Sculpties are like the "animated gif" from the early internet days. A stop gap, but still with us in situations where bandwidth and resources is an issue.

Instead, I recommend using them to extend the "brush shapes" we already have in prims, like 3d "potatoe painting". Obviously, the result can be very chaotic in terms of textures, but its also a lot more fun than working outside of SL to build things in, say, blender then bringing them in and hoping for the best. Overall I get some nice organic shape results, which are all but impossible with the overly perfect prim shapes. Ive made some great trees, sticks and rocks with very few prims.

I agree that we need more precise tools in world, and as long as we can continue increasing the user experience in terms of less crashing, Im all for it.

Uhhh... I hate to be the bad guy but... how is that going to stop noobs from uploading model that they didn't make? (downloading from endless junks off the net to upload bunch junks for profits.)

Sorry, I'm kinda against this idea.... yet, I do want a better way to do sculpty.

However, I've been working with sculpty long enough. At first it was hard and I hated it... but more I've dealt with it... it got easier and gain more tricks. Enough to say... I can live with it.

I heartily agree.