Teleport to, Swimming animation, cache permanent locations/characters, Importing 3d

TELEPORT TO:
It would be nice to have a favorites menu of all your favorite locations. It could work similar to IE. This would make it more convenient. Also, a possibility to hide/unhide your current location would be great. If your location is unhidden, and your on someones favorites list, they could teleport to you without you giving them an invitation.
VOTE HERE: http://secondlife.com/vote/vote.php?get_id=2426

SWIMMING ANIMATION:
I noticed that when a character goes underwater, he doesn't have a SWIMMING Animation. This is noticed with the normal default avatars that you could make with SL. It should be a bit more realistic.
VOTE HERE: http://secondlife.com/vote/vote.php?get_id=2427

PERMANENT CACHING OF CHARACTERS AND LOCATIONS:
This could save loads of load time if we have the option to download the texture packs and locations to the harddrive as we go through them, making it always appear available. Even with inventory items. Just download it. This way in game there is less to load and smoother transactions. It does have a caching system, but it needs to work this way. The software could then load and download new textures as they are added. It could check for changes every 30 seconds or something.
VOTE HERE: http://secondlife.com/vote/vote.php?get_id=2428

IMPORTING YOUR OWN 3D OBJECTS:
I find that making objects in SL is a bit tedious. I am much more used to using Blender and Poser. Maybe an import script for those and even Quake and Half life files would be nice. Even 3DS. They are all open source or in someway implementable. Maybe create a converter to do that for you. 3DFILE to SL3DFILE and then import the SL3DFILE.
VOTE HERE: http://secondlife.com/vote/vote.php?get_id=2429

IMPLEMENTED SINCE FOREVER.
Since the invention of mapping we can TP to someone else.



Never going to happen. We use primitive based modeling, while 3D apps use polygon or nurbs based modeling (even for their "primitives".

Yeah, I kind of meant like having a favorites menu like in IE. With that you could easily choose the location from a drop down menu and then teleport there. Also, part of teleporting is teleporting to someone who gave you a card. Right now, all you can do is give them an option for you to teleport them to your location. Maybe we could have an option which each of us can use on our own. The option would be 1) Allow people to teleport to our location 2)Disable teleporting to our location. This way if its enabled, we can teleport to them.

As far as importing 3d characters... It can be done. Maybe an external tool can be made to convert the file and then import it into SL.

What a convincing argument!

No, it can't. The shape data for an arbitrary mesh is completely different than prim construction. Prims don't store the vertices, just what objects are where and what size. The best they could do would be offline building using prims, and there are already tools for that. Look in the Building forum.

...Did you not see which part I gave emphasis to in my quote? He wants to be able to teleport to people who have him able to see them on the map.

Man. Stow the sarcasm. What do you think prims are? OpenGL doesn't magically know how to render a cone or a sphere or a cube. The geometry is all constructed from vertex meshes in EXACTLY the same format as av meshes. And before you say that these primitives are generated algorithmically, perhaps they are at first, but they are uploaded and stored on the GPU as vertex meshes. The only difference between "prims" and avs is that av meshes are passed through bone and shape deformation before being submitted to the rendering pipeline, and even these are just a series of highly hierarchical matrix operations that are NO DIFFERENT from the matrices necessary to reshape prims.

Ostensibly it would be beyond trivial to create a new prim type that is an arbitrary but static mesh imported from some other file format like FBX, OBJ, etc. Collision detection could be handled using primitive bounding volumes.

That being said. Mesh data is probably not sent over the net at the moment. The client knows what cones, cubes, tori, spheres, etc. look like. All that is needed from the server is a single transformation matrix to tell it how to deform the prim. In order to implement an arbitrary mesh, the SL protocol would have to be able to send vertex data. That might be a burden on bandwidth, but there are things that can be done to mitigate. The Lindens could impose a maximum polygon count and even a maxiumum size on such a prim. They could even impose a limit on the number of such prims an av could create in world. And I'm sure that there are lossless compression algorithms that would work on vertex data. Texture data is streamed and cached. Why can't vertex data? TCP/IP doesn't make a distinction between the two.

I'd gladly tolerate a little lag if it meant houses and vehicles and attachments that didn't suck. Besides, it's not as if SL is all that lag free anyway.

That was a good explanation Nynthan.

You're right, it isn't being sent, and that's the issue. The prims and avatar meshes are stored locally, included with the client when you download it. It would take much too long to transfer the data. While small numbers of vertices wouldn't be much burden, polygon counts that low would be pointless because then you can easily construct the shape out of prims. Allowing arbitrary meshes would only be useful for medium/high poly objects, like entire custom characters, and that would be a lot of data.

You are correct that the amount of data would be comparable to a really huge texture, which is why SL was recently changed to disallow really huge textures.

ADDITION: I may regret posting this little addition, but note that I am perfectly aware how 3D rendering works. If you'll look at the stickied threads in the Texturing forum, you'll note I wrote an app whose sole purpose is to render SL avs with textures on them. Please don't yell/all-caps for emphasis, it's patronising.

Thank you for that analysis, Nynthan. I totally agree, too. Some beautiful things are being created in apps like 3DS, FormZ, and (gag) AutoCAD. I have designed in all of these apps and have converted my objects back and forth for years. If I can succesfully convert an object from FormZ to VRML and back again, I would think there is some way for LL to write a "converter" for the most popular 3D design apps. Will it be easy? No. But it is possible.

On that same note, it would be nice to be able to export your objects from SL into said apps. I would love to be able to use a top-rated 3D design tool to create, say, the perfect chair, be able to import it into SL and try it out in-world, THEN be able to make modifications to it in-world and export it back out. LL - if you are listening: please try 3DS and FormZ first (big hint).

Ahhh - my wish list for the year. But if you are going to dream, at least dream big, eh?

I have given all 10 votes to this one....

Just a couple comments. About the swimming, SL does have some built in functionality concerning swimming, but for whatever reason doesn't implement it. However, I have found an AO you can wear which makes your avatar swim properly when in the water. A little searching in world should lead you to it.

As for caching characters/textures/etc. locally, I don't think SL will ever have this, as it would open the possibility of reverse engineering protected content, and not only that, SL is too dynamic, things just change too often to make it practical.

Also, Linden Labs has already stated that uploading of mesh opjects is a goal of theirs and will be implemented when it becomes feasible.

It's nice that you did learn your lesson on 3D, yet SL is already a slow mammoth and you want it to displaya arbitrary shapes? oh yeah sure, in another life maybe.

For the objects that don't suck, well you will just have to try harder building.
Polygon modeling is just not suited for a streamed environement.
And if you allow .3ds import whee the copyright violations "gasp"

And i thought you knew the 3D modeling was an ever changing method, if you can't bear the learning curve of new softwares (o just different softwares) you might consider stopping alltogether.

Wow - it might just be the method of communication - but it's unfortunate that some responses come across as being filled of attitude. People don't act this way face-to-face....

Kyrah, never say never. The comment "you want it to displaya arbitrary shapes? oh yeah sure, in another life maybe" is akin to the 1985 statement "no one will ever be able to fill up this massive 20mb hard drive." Technology changes and what does not seem possible now will be possible a year from now. My wish for the import/export of shapes is directly related to my job as a computer lab instructor for Cal Poly State U. Our Arch. department would like to use SL as a platform for Arch. students to design structures and then be able to "lead the class through them," however, SL currently has limited design and building tools that don't meet our qualifications. So, just like in real life... If you see that something doesn't meet your needs - don't just resign yourself to the existing method. Instead, redesign your world.

Now that SL is open source, I think we'll get this wish granted sooner than later. It is definitely my goal for this year.

As far as copyright violations... This problem already exists in SL through the importation of trademarks in textures. LL is dealing with this issue on a case-by-case basis. As SL evolves, copyright abuse will be as important as any other TOS violation, and will be taken care of in the normal manner. I'm not too worried about it.

I guess the bottom line is - the building tools in SL are fine, but as SL attracts professional designers, there should be more options available. A lot of bandwidth is taken just by the act of building - which for complex objects takes a long time. If you could build the object offline and then upload it, I think overall bandwidth would be reduced.

Just a thought.

Ample arguments for or against. I read in another thread that LL's main concern with meshes is level of detail calculations. How do you decide to trim vertices off of a given mesh at whatever distance? You'd need to force people to upload reduced poly versions of their meshes, or else REALLY sit and think about that problem so any arbitrary shape can be reduced in polygon complexity at a distance. Now that the client's open source, I'm sure people will refine the graphics engine and make it friendly for lower end systems (like mine which struggles along on 512 megs of RAM). In time, meshes might be allowed after that.

I do have to agree with Kyrah however. Dispite SL's limitations compared to a fully featured 3d tool like 3DS or Maya, people have made some very detailed and inspired constructs with just prims. I invite you to visit Svarga for some interesting architecture (and enjoy the ALife ecosystem while you're there), visit the many Gorean ports or elven glades out there to see some examples of old school building or natural scenery, and although it's rather vain I feel I did a good job on my stairs in Serenity Woods (they span a large area up a mountain side). It's a matter of effort, you CAN make great stuff in SL. But I know what you mean, why force students to learn SL's building system when they won't be using that professionally. Still, the idea of a good structure can be taught in SL, if not the tools.

That's a really interesting point. I think that there are algorithms out there that can automatically reduce polygon count. And I'm not talking about meshes derived from nurbs or hypernerbs cages either. But I can't imagine that any such algorithms would be simple to implement. But as it stands, I'd be satisfied with rendering a simple bounding primitive at a distance, and only rendering the full mesh within a certain range. And this range could be configurable.


I didn't mean to dis builders in SL. If that's how I came across, I apologize, although I don't see how my remarks, by any stretch, warranted such a childish and condescending reply from Kyrah.

I fully admit that I have been awed by the beauty that many citizens have wrought from the limited shapes at their disposal. One solid example is Cave Rua. However, the shear effort required to do this, might be so effectively alleviated by the introduction of a rudimentary arbitrary mesh primitive. A cylinder, up-close, seems to have about 20 facets around and about 14 or 15 segments vertically. With the caps, that's 320 to 340 quadrangles. I imagine that tori and tubes have an even higher polygon count. That's enough to model a pretty decent face, or even a rudimentary human figure.

And if it's streaming we're worried about, what about a simple nurbs patch? A 10x10 nurbs patch could be easily streamed, and could provide for much more organic shapes. And it would also provide easy polygon reduction.

http://www.activeworlds.com/

Active Worlds has been using meshes since the dawn of time. It's hardly state of the art. Any excuse given against them is just a cop out.

Nynthan, don't take it personal. Kyrah is notorious for being that way. Just brush him off and move on

Welcome to SL!

SL would render much faster with meshes.


You can only do so much with primitives. They're just primitive after all. If you try to make anything other than a house, then it's probably going to suck. Sure, some people try to make interesting things like sculptures. But those sculptures are only good within the context of Second Life. Put them next to a sculpture made in 3D studio and they just plain suck.


Judging by the amount of pop in that we already have with primitives, it would seem nothing is suitable for a streaming environment.


I think Linden Lab gave up on copyright issues when the Copybot arrived.

Thanks!

Heh. Looks like someone should take his own advice about learning before mouthing off.

Heh i have nothing to regret about my attitude, it is the result of ... years of deception.
Honestly only a bad artist complain about the quality of his tools.

Yes prims aren't the best thing exactly related to rendering effectiveness however we can 'describe' with them quite complex shapes (although they stay limited i agree) using only a handful of parameters when the same shape, described using its vertices would result in MUCH more data in the already clogged SL network.

Well, I'm sorry that you're so bitter. But go pick on someone who made you that way.


Honestly, only the infantile resort to personal attacks to support their baseless arguments.


When was the last time you considered the texture to vertex bandwidth ratio? Try NEVER. Take a basic 256x256 tga file. It's what? 300kb? That's 30720 bytes. At 8 bytes per floating point number, and 3 floating point numbers per vertex, thats 12800 vertices that could be streamed every time a texture is downloaded. An avatar is prolly at most 3000 vertices. So everytime you get a new texture in your cache, you could have downloaded 4 completely custom avatar meshes. All I'm asking for is a measly 10x10 mesh. 121 vertices. 3kb.

And even if we consider that prims are transmitted by parameter, examine the lslwiki on llGetPrimitiveParams. Each prim requires 15 parameters: SHINY (4 bytes), COLOR (4 bytes, conservatively), FLEXIBLE (64 bytes), FULLBRIGHT (4 bytes), MATERIAL (4 bytes), PHANTOM (4 bytes), PHYSICS (4 bytes), POINT_LIGHT (52 bytes), POSITION (24 bytes), ROTATION (32 bytes), SIZE (24 bytes), TEMP_ON_REZ (4 bytes), TEXGEN (4 bytes), TEXTURE (minimum 57 bytes). That's 295 bytes per primitive.

Now consider that the Starax Samson is 235 prims, just for Samson, sans pedestal, pillars. That's 69325 bytes. That's enough to send 2888 vertices. I can create a pretty decent mesh sculpture of a humanoid with half that number of vertices. And I'm not even advocating that much.

excepted you forgot that the textures are compressed to the JPEG2000 format, what is important isn't really what is rendered but what volume is to be downloaded.

Um...you also forget, that your 'humanoid mesh' also need at that 256x256 texture image that need to be downloaded, unless you don't use any texture. Which, in that case, the vertex download will take much more than prim-base. So you won't reduce any traffic at all, just increase it.

Um... you also forget that a prim sculpture also needs a texture. So it appears that traffic is reduced after all.

Yes, but his original post say mesh vertex download take less time because the size of the mesh will be less than texture ;p So mesh size+mesh texture must be prim base+texture right?