Anyone working on the technical challenges?

While I found parts of townhall a bit distasteful (feebs and choads? is that how he sees people who don't fit his staffing needs? Niiiice), my curiosity was piqued about the technical challenges that were posed in the town hall.

I've enumerated them here for easy reference. I've started looking at them all and include some (yes, fairly ignorant, I'm not graphics guru) notes below. If you have some thoughts or just want to talk about them, post here or IM me inworld.



My notes:

1) CrystalSpace (the open source version of a potential SL graphic engine) has some code / interesting ideas on imposters. If anyone is interested in persuing this one, they'd be a good research starting point.

I believe the challenge here will be more iterating the full set of primitives into a data descriptive format which is useful for various challenges. However, the beauty is that once we have that we can go on to build tools outside of SL

I suspect peeking into the metaverse(.sourceforge.net) code pace might provide some hints as well. My little pinky (or maybe it was eggy tells me that hugh is wise enough to try to leverage the contents of the SL for his project.

Another reference:

(http://www.cs.umd.edu/~jra/gen1.pdf)

The idea, of course, is that procedural based generation of graphics is a highly optimized stream (too bad the textures are the bottlneck!). To repeat, now we need to reverse engineer and rewrite those procedure definitions for SL primitives outside of SL.

Of course, we then have the fun task of creating the imposters. HmmM! And as for the lit aspect, hmm! Not sure. This is all just fun brainstorming.


2) Yeep. This seems pretty cool, makes me think of Genetica 2, maybe? Sounds more like a tedious programming effort than a 'technical challenge', though.

3) Create an optimizer for transforming arbitrary 3D mesh geometry into SL primitives. The optimizer would need to be able to tradeoff processing time, error, and number of created primitives.

Now this should have been #1. And I have (so has Jeffrey, to more success) tackled this one.

How do we take an arbitrary 3D mesh and break it up into SL like primitives? Not sure. I think however we may have to force LL to compromise and enable a few more primitives which would make this problem more tackable. Right now I think the current set of prims are for in world building of interesting things and less about translating arbitrary 3D objects into procedural primitives.

If not, then I think key would be to re-use the effort that went into #1 somehow for #3.

4) Yeah, give us LSL commands to manipulate other people's avatars or give us the ability to build and automate our own avatars. I'm sorry, but building a computer out of tiddlywinks is not a technical puzzle, it's an exercise in futility.

Though, again, Jeffrey has some very very clever stuff around here if you really felt the need to tackle this one (yes, yes, we are not worthy, jeffrey

5) Ahahahahahahaha! Good one! I can't even get my dragon naturally speaking to work properly! and 6) (this where I'm starting to feel like this is all a tasteless joke meant to waste everyone's time) If anyone took these two options seriously, please, let me know.
I'd be interested in understanding your reasoning.

7) "different combinations of legs" .. does that mean like quadripeds? Anyone who knows more, please post..

Anyways, these sound like kinda fun. Hopefully people will take the time to think about and discuss them. Even if they don't get integrated with SL/LL, solving these problems (1 and 3, especially) would go a long way to developing tools outside of SL that we can integrate via commands like llSetPrimitiveParams

I'll consider adding the first three into the Blender tool I plan to make. That's my project once this whole Game Dev thing finishes.

And thanks for the plug.

I talked with Cory about #3 specifically. What he wants is an optomization algorithm, ie. if a mesh is a sphere in the editor, it should be able to figure that out all by itself.

I can't stress how difficult/time consuming an algorithm like that would be to write for the average resident. Especially in a not-for-profit environment. Instead of this, I plan to emulate the primitive system in Blender... and already wrote a couple test shapes to boot a month or two back. The problem for me now is time - in addition to Game Dev, I have a part time job and classes this summer to contend with. Social life is in there somewhere, honest.

-----

As for incenting users to create this stuff:

First of all, it might behoove LL to place a bounty on some of these milestones, either in L$ or real world dollars. I could care less for the money myself - since I plan to write some of this stuff regardless - but something like that might get other people motivated to "help LL help everyone else."

Second, it might be wise for LL to share some research or aid in conquering these milestones. SL has many creative individuals, but not all of them have the resources necessary at their disposal. My sigline link contains some good examples.

Finally, this brings talks of a Second Life API back to the surface. If we're to truly excell, plugins and tools will need some better/easier support. At the very least, two way XML-RPC or a text dump utility would help tremendously.

But ehhh.... I'm just ranting. Time... all in due time...

Well, I think the most interesting one is #3.

While it's most likely that it is very hard to do, it's not a foregone conclusion that implementation time needs to be that frightening.

For example, I could think of some inefficient algorithms which could brute force the solution but would unfortunately become astronomically expensive as 3D meshes became more complex. Basically, create a search space and then walk through it until you find the cheapest solution (you could even set weights to particular primitives).

Of course, this is starting to sound NP Complete. However, this does make me think back to alg classes and techniques such as divide and conquer to reduce the average o(N^K) time to something a bit more reasonable. Or, like chess algs, spend time pruning branches that are a waste of time going down. Worse case, of course, will probably always be exponential.

Anywys, personally, I'd like to focus on #3 myself (which really should have been #1).

Ideally, we could develop a solution which would go both ways, though obviously out of SL is much easier than into SL and a solution which could be used to tackle #1.

As far as I know, #5 is going to be impossible to do in SL without some form of 'helper application' running in the background, but #6 is quite practical and can be done fairly easily (and might not be a bad way of making interfaces better)

-Adam

On #3, the problem isn't "figuring out the mesh" per se - it's figuring out the "best fit" to it.

I could tell a mesh "make spheres out of this" until the cows come home, and the algorithm would not be all that expensive. But when you consider 7 candidate prim types with a nearly infinite number of permutations and types, and you're trying to find the best "fit?"

This could take a while.

Honestly, the simplest solution is to emulate the prim system. I've already been given the okay to do this, and in the long run, the benefit is greater than "guestimating" a shape. Why bother when you can just create the shape?

That's what I'm getting at here. In the spirit of making the thing relatively inexpensive on the CPU and easier to understand, I see creating the prim system out of SL as a much better design. And that's what I plan to shoot for sooner or later.

And as a followup, I forgot to mention: I intend to include more user-friendly versions of the 3D Model Importer, BVH-to-Prim Importer, and Prim Mirror in the Blender tool. Since I have all of the hard work out of the way, that shouldn't be too much.

As for a more simple, alternate solution to #3, see my case study on rendering. Since we can already import prims as polygons, being able to fuse them together (read: meta objects) would solve this problem quite handily.

As for making things more "prim efficient," I'm going to go with the fact that nothing beats simple human thinking. Being efficient with 3D models is an art, not a science.

Making it perfectly efficient is nigh impossible.

Oh, and this completely leaves out the problem of textures and UV maps. Excuse me while I allcaps for once:

WE NEED BETTER CONTROL OVER TEXTURES TO PROGRESS!

While the talks of moving to a materials system give me some faith, texture processing is a major stumbling block that leaves this whole mess incomplete. I tried making a UV map importer for just simple triangles, and failed horribly. The current texture system can't even sustain that.

Some thoughts came to me in the shower this morning about this problem.

I think #1 and #3 are potentially the same problem.

Basically, with #3 you are building imposters, which given a set of triangles describing various volumes (a) and a set of primitive procedural volumes (b) you can get arbitrarily close to fully representing the volumes (a). Theoretically, since we have the triangle primitive we can get exactly close.

For example, if you calculate a bounding box you can just use the box primitive. To measure how close you are you can caculate the total volume by subtracting the target volume from the box primitive.

The first problem is solved by first translating the primitives into a set of triangles describing various volumes (already done by SL...) and then using the solution described above.

In theory, as you get physically closer (distance wise in world) to the object and the LOD increases, you would attempt to get closer (volume wise) to the target volumes.

Does this make sense? Or am I way off track?

i don't know if they ported to open gl, but authorware by macromedia-now-adobe has something like this.

you still need to learn how to program to do interesting things... though you get to basic control flow faster this way.