2 things that would inprove the game 150%

Create your own importer.

1) Write a program which converts your favorite 3d format to an easily parsable text file.

2) Paste text file into a notecard.

3) Drop notecard into a scripted object which reads it and then rezzes/reorients very flat prisms (triangles) accordingly.

The end.

Have fun =)

Edit: Step #1 may have to be written to covert quads to triangles if your 3d format contains them.

I kinda doubt they'll make any money from licensing the polybump product seperate from their engine. It was one of those ideas that probably came from a siggraph paper and everyone is jumping on the bandwagon. I would imagine almost all next gen game engines will start using something similar. 3ds Max 7, which starts shipping in a few weeks, has normal mapping as a feature. It's every bit as useful for people doing film and broadcast work as it is for game engines. Incredible levels of detail without the painful render times of scenes with several million polygons. I can't wait to play with it.

> Create your own importer.
>
> 1) Write a program which converts your favorite 3d format to an easily parsable text file.
>
> 2) Paste text file into a notecard.
>
> 3) Drop notecard into a scripted object which reads it and then rezzes/reorients very flat prisms (triangles) accordingly.

Actually, this is possibly the nub of the matter which leads to the idea that meshes are too large to be used in SL.

If you convert a mesh into SL primitives, suddenly each bit of mesh becomes a fully-fledged primitive in its own right, with all the attendent transforms and so on (as Morgaine says).

If you take a raw mesh, even uncompressed, as Eggy says the size is actually fairly comparable to that of an image file.

Now, obviously if you applied no filtering then there would be people using a 10,000 triangle mesh instead of a sphere, but there's no reason why you couldnt just assign a primcount appropriate to the bandwidth cost of the mesh. Then it's up to the user to decide which one is more efficient and more appropriate, depending on their specific requirements.

Azelda

Exactly, Azelda.

That's what progress in engineering is all about, tradeoffs, bridging the gap between the impossible and the already existing by finding a way to implement the new without exceeding one's resources.

There is ALWAYS a way. It's a pity that more people don't focus their attention on how new things can be achieved instead of on why they are impossible.

lol, SL isn't a new enough thing for you? When you've programmed your own fully streaming 3d world that allows arbitrary mesh objects let me know. In the meantime, try giving LL some credit for what they've achieved here.

I don't know why you say that, Chip. Pushing for progress doesn't in any way detract from what has been achieved already. LL are completely out ahead on their own at the present time, how could anyone doubt that what they've achieved is remarkable and praiseworthy? The fact that we're here and not elsewhere says it all.

But that is no reason to stop forging ahead, at full speed. The minute you do that, you're on the road to becoming history.

And no, nothing in the present is ever good enough for me, because my eyes are always set on the future. You'd do well to emulate it too, not because of me, but because that's exactly what the people at the helm of SL are doing. You seem to enjoy backing the status quo more than the leading edge, as your post shows. Well, fine. But please don't try to hold back those of us who are more progressive than that.

I give LL far more credit than you do. If you think they're resting on their laurels then I think you're mistaken. Imported mesh objects was an obvious thing to consider, which they did and chose not to implement them for reasons already posted in this thread. They're not going to read this feature suggestion and have a forehead slapping epiphany. "Why didn't WE think of that?!" Someone has brought this up about every two months since beta. Now if you want to make some useful suggestions, try coming up with ideas for the ratings system, or the new permissions system, or other areas where it's something they didn't already think of on the first day of development.

Uhhh... no offense Chip but OSMP does support arbitrary meshes

Well that statement is extremely funny, and I think that it's insightful about your position too.

Because you see, you want to give them credit even for things where they are lagging behind the industry, or which show poor use of computer science principles and which we are trying to improve. It is you that is actually saying "They are good enough already", so it's you that is wanting to hold them back and rest on their laurels.

Well I have news for you. LL is not resting on its laureals, despite your fervent wishes and your attempts to block new features. They are far more visionary than that. So you are not helping their cause at all, in being basically regressive. LL *want* to work with the community in adopting hints and features from us, as they have shown on many occasions.

"Praise without criticism" is an *exact* definition of fanboy, so if you want to avoid that label, you need to go beyond just praising them for past work, and be ready to criticize constructively those areas of SL that need improving, and to offer solutions where you have technical knowhow. That's what we are doing. Try to help us please, not hinder progress.

Morgaine,
you have continually accused Chip of being a Luddite, I think you are suffering from the misapprehension that he is against change in the game. What I have read from his posts it that he is simply stating that given the current tech, that mesh-based prims/objects are too far ahead of the internet tech. Even those of us on faster than average connections still do suffer "rez delays". Why make the latency issues and the server load any worse than it currently is? To put it bluntly, you want meshes in the game, thats like trying to stuff ten pounds of shit in a 5 pound sack.

There needs to be a balance between the tech and enjoyment of play, and I am sure these are envelopes that LL are constantly pushing.

But that's precisely the point --- we are proposing solutions and methods of applying meshes that would NOT go beyond current capabilities. Those that are arguing against meshes entirely are saying "Well some huge unrestricted meshes would take us too far, so all meshes are bad." Well DOH!!!!! We're not proposing that.

I'm a professional engineer, and my feet are very firmly on the ground, so I don't defend things that aren't within the current sphere of possibilities. And I know that they are, because this is the area that I work in. I do make mistakes like anybody else, and I'm happy to have potential problems pointed out to me. But it has to be a major showstopper to halt a line of development entirely, because it's almost always possible to find a new approach or a compromise that works. That's what engineering is all about.

/chuckle

I'm getting the distinct impression that some people don't realize that the SL client is full to the brim with meshes, and not just for avatars. Prims are geometric mesh generators which churn out meshes dynamically for the hardware to render. There would be no SL without meshes.

So what exactly is the difference between a mesh ONCE IT HAS BEEN DOWNLOADED AND PROCESSED and a mesh that a geometric mesh generator creates? Absolutely none, the graphics hardware couldn't care less which it's rendering.

In other words, when objects defined by user-supplied meshes are held in the cache, there need be absolutely no difference in terms of client performance between rendering them and rendering prims. In fact, the meshes require less effort to render, since prims are continually reprocessing their dynamic meshes to achieve an appropriate tesseleted resolution.

In other words, the whole issue about user-defined meshes boils down to defining appropriate constraints to limit bandwith usage for when the meshes aren't yet in cache, or for when they have new deltas compared to their cached versions. That's just engineering.

Here's one more example of engineering compromise and tradeoff in action. There are countless such schemes that one can come up with, as long as one avoids the "no it's impossible" mentality.

Consider an almost totally arbitrary mesh of unrestricted size and constrained only by the mesh topology validation that limits it (on input) to whatever topology the renderer can handle. Just one overall texture, as this discussion is about meshes, not textures. Let's call it a Deferred Loading mesh (DL), for reasons that will become apparent.

Now here's the proposed MO that carries the compromise: a DL mesh is defined as a mesh that is only ever downloaded to clients in their idle or spare capacity time. In the absense of a particular DL mesh in a client's cache, it is represented to the client by its bounding box only, and the resolution of that bounding box is extremely coarse so that it presents no discernible download overhead. The DL mesh is never ever downloaded while you have other things to download and no spare bandwidth, that's the compromise.

This seems a terrible compromise at first sight, but here's the carrot: it costs you just 1 prim, regardless of the size or number of vertices in the mesh. (I'm not talking about textures, but if I were, I'd probably make that cost equal to the number of textures.)

[By the way, I'm merely discussing technology here. LL make their money from hosting prims and this would reduce the usage of prims a bit, so they'd probably want to increase the cost of DL meshes above 1 if they had them. That's fine, that's a business decision and not a technological issue.]

How can I make such an astounding offer, arbitrary vertices for a trivial cost? It's easy to make, because it costs nobody anything beyond the coding effort. Here's why:

You will only use DL meshes for long-lived and unchanging constructions, because of the loading penalty, so a DL mesh will be downloaded infrequently and therefore not cost the server much download time. It's only downloaded in your idle or spare capacity time, so it doesn't cost you anything at all on the network side. And once in the cache, it uses even fewer client resources than prim-generated meshes currently do, so there's a net gain from the client's perspective.

There you go, one mesh-based scheme that provides everyone with net gains, except those who want their constructions to appear instantly --- well they can either continue to use only geometric prims, or they can first construct with prims and then replace a composite object with a DL mesh once they've finalized their development. Or they could replace only the invariant structures with a DL mesh, and leave the varying parts still implemented with geometric prims.

I'm not necessarily proposing it, I'm just making the point that given a flexible outlook, a desire for progress, and the acceptance of engineering tradeoffs, almost anything is possible. Nobody's asking for warp drives.

Edit: By the way, Eggy, how about DL meshes for OSMP?

Well Morgaine. Since you're so much smarter than LL perhaps you should send in your resume Personally I think you're talking out of your ass. I happen to be a professional animator. I don't need you to explain technology to me any more than LL does.

And I'm not trying to extend your knowledge from animation to software engineering. It would however be nice if you refrained from trying to hold back discussions outside of your area of expertise. You won't find me trying to tell you that you're wrong about animation. Each to their own field.

Okay Moragaine... wow, that's the largest penis I've ever seen! There, happy now?

Someone suggested it earlier, but I'll suggest it again.

Instead of trying to have SL import meshes or nurbs or what have ya, why not allow a way to import objects created in a format that SL recognizes? Would it be possible for to write a plug-in for one of the 3D packages - Lightwave, Maya, Blender (not sure it supports plug-ins.) The plug-in could speak the language of SL or even present the user with the same edit interface and objects as SL does, allowing only objects that will work within the SL world.

If not, a text-based renderer would work for those who have very limited time online, but really like building in 3D. Anyone remember POV-RAY before it had a GUI:

box{ <0,0>,<0,0> pigment{color red}}
sphere{ <5,5>,2.5 texture{pigment{color gray}finish{shiny}}}

Then again... maybe not

Sure, this could be done. Currently SL doesn't recognize any load format at all, so essentially this is a proposal that a load format be defined in terms of SL's prims, so that people can write external converters to it or even brand new SL-specific modelling applications.

Conversion from a mesh to SL prims probably wouldn't be particularly efficient because you're going from a low-level format to a higher level one and conversion is typically easier in the other direction, but it's possible. A brand-new app that modelled in prims directly would probably be a lot more efficient in prims, but less desireable in that it wouldn't leverage existing 3D modelling tools. Still, both approaches are definitely feasible, and I can see how they would be of benefit in some situations.

This actually is an example of a couple of elements in a possible prim-based load format. Before anything like this gets fleshed out as a proposal though, we ought to look for previous postings with prim load format suggestions first I think, because it takes a lot of time and effort to do that properly and effectively.

It would need to either allow hierarchy and implicitly link up subtrees into SL composites, or alternatively to use a flat design with labelled prims followed by a linkage section that references them for linking. And it would need to allow all the prim parameters to be specified, including distortions, and the texturing details would need to be per-side. Quite a lot there to consider.

Has anyone kept any references to previous proposals on prim-based load formats? And to discussions about what would be the benefit of doing this, given that object rezers have already been designed to load the prim design format of your choice? Maybe you should be calling for folks to post their rezer load formats instead.

This is sort of orthogonal to the discussion about meshes, but there's no harm in having multiple ways of defining the world.

I mentioned 3rd party plugins here:

/120/ec/24256/1.html

I think it's a great idea, but companies/individuals have to have some real incentive to do such things, which is where LL really needs to get on the ball and spread the word and really schmooze up the 3D community and get some real widespread support, otherwise it'll flop just like so many other VR programs of the past (and I think that definitely LL is doing a lot of things RIGHT compared with previous 3D VR universes, so this shouldn't happen, plus their user base is already huge compared to previous attempts at building the metaverse!).

My 2 cents,

Arti