So for starters, here's the stuff I'm going to be laying out here:
- Curved Edges on Prims (rehashed)
- How to Improve Object Quality through the Client
- Rendering - Second Life versus Standards
And the actual suggestions:
- Prim "Merging" and "Subdivision"
- Rendering Options - What We Want and How to Add Them
- Stuff We Want that Isn't So Easy
I'm also writing this before I crash for the evening... so bear with me, folks. Everyone who doesn't give a care about technical details is excused. See pictures below.
As for all three of you still around, let's begin.
Second Life has progressed in many ways. One place where it's lagged, however, is in its capabilities to render detail. Sure, we have those incredible SL 2.0 renders with draw distances rivalling reality... but sometimes quantity just doesn't make up for quality.
A better draw distance and finer detail need not be mutually exclusive goals, so long as the client makes the right decisions about each. More on that later.
Furthermore, simple things have been requested from the renderer for some time. Things like rounded corners on primitives, a feature that has been requested a couple hundred times; so much, in fact, that I dubbed it the most popular feature request I have ever seen on these boards. That ties in to this as well.
...
So how does it work, McGee?
The Setup:
Scroll down to the attached picture file. Let's suppose Figure 1 is two cube prims that intersect at the center. Now, let's do something interesting. Instead of having those prims function as separate entities, let's have them act as one "object." I use object because this would mesh handily with Linked Sets.
So, first, suppose we have now "connected" those two prims. This can be done fully inside the client with some fancy vector math and existing link behavior, but unless you study this stuff like me, we can leave it at that.
Now, let's Doo-Sabin it. Doo-Sabin is a fancy term for "subdivision," or more simply, smoothing. Only, let's smooth the surfaces outward to form curves.
Confused at the significance of this? Have a look at Figure 2. Here, we perform the same "trick" on a standard surface. Note the more you perform the algorithm, the more "smooth" the object becomes.
As many people know, organic modelling has traditionally been very hard to do well in Second Life, because each "prim" behaves as its own object. So right off the bat, organic modelling would suddenly become more feasible, and look damned good.
In other words, blending multiple prims and smoothing them would add a whole new world of depth to Second Life.
And you know what's really handy? Used with single prims, this method would happy create curved edges! And with Havok 2 forthcoming, physics is less of an issue.
Though to be fair, this stuff need not be physical.
But Wouldn't This Be Laggy?
Yes and no. From the server's point of view, all we'd have to do are add a couple extra settings to something like Bumpiness... meaning no increase to latency at all. Of course, something more advanced would be nice. My example in the upper left of Figure 3 is more geared for the long haul. More on that later.
As for the client, just add this stuff to preferences! Low end systems would choke on this stuff, so an effective distance for subdivision, as we already have with bumpiness, would work nicely.
As I see it, if the client were to render this detail on demand at very close range, it need not conflict with the draw distance improvements planned for SL 2.0. It'd also help to nail both ends of the spectrum, to satisfy power users and general folk alike.
So What Results Should We See From This?
See the last images attached. I've used my two favorite models (which I made myself) for this demonstration. Pictured to the left is how this stuff renders now when imported. The right renders are done in a free program called Blender, which also happens to be open source.
I don't think I need to point out the differences in the two. Almost apples and oranges in how they're done. I feel improving the raw rendering would help on so many levels, though.
Oh, did I mention something like this is fairly lightweight, code-wise? At least, it should be. That means the client download needed would not be huge.
And, for that matter, I'd endorse digging through Blender's code for render improvements.
What about the industry?
As for where I feel we're ultimately going, but won't be there for a long, long time, there are several render "tricks" that would ultimately benefit Second Life. Some examples include:
- Shader Technology
- Normal Maps
- More Robust Multitexturing
- Specular Maps
... etc. Obviously, most of this stuff will not be added any time soon. Furthermore, they'd grow the size of patches considerably. It is, regardless, something to think about in the meantime.
With the rise of more "open" applications of Second Life, this kind of stuff might even be added by residents. However, that too is far off.
In closing, I hope someone out there understood my tired rant on this subject. I feel Second Life is in many ways still "behind the eight ball" with what it can do in the renderer. Hopefully, with stuff like this, that'll improve over time.
Because, hell - the technology is out there and ripe for the taking. All it really requires to get in there is perseverance and the want for it. Hopefully there's enough of that left to go around.
