FEATURE SUGESTION: polygon objects, or primitives that allow edit of vertecies
|
|
lyndell Aleixandre
Registered User
Join date: 17 Oct 2005
Posts: 5
|
01-19-2006 04:56
hey guys .. this would be the first time ive posted since i am a passive observer i normally wouldnt post anything here unless i have a good sugestion or it was nessesary, anyways on to my sugestion(and WARNING!!! BIIIG post and sorry if i repeat myself on this) :
i prepose we have polygon objects, as in objects that are not primitives but polygon meshes.
these objects count as 1 prim, would eliminate massive rendering lag , MASSIVE! .. since polygons are optimised where as a whole clump of primitive objects renders massive amounts of poly's that arnt seen, it would also address prim limits .. since you can have a very detailed shape that would normally have to use hundreds of prims to atain that detail, veicle prim limits would be releved for now , since you only need 1 or 2 polygon meshes to make a fairly decent looking veicle.
server/client overheads associated with updating hundreds of objects in view and bandwidth requirements would severely decrese not to mention rendering would be much better.
i talked to a linden about this feature and he told me that it wouldnt be possible .. *1 how can this not be possible *2 avatars are poly objects that are infinately customisable in shape and form, why can this not be possible with objects? *3 understood that avatars and objects are entirely diffrent catagories , and that programming this catagory in the object system would be difficult, however given that secondlife has had a considerable amount of its code base changed , not to mention how the server/ client transmit and communicate etc...
how can a small change like this (in comparision) not be implimented .. sure there can be bugs accociated with implimenting this , just like there will be bugs implimenting havok 2 , either way... just like havok 2 this change is inevitable and will have to come sooner or later, the only diffrence being that this change will make sl much more enjoyable/playable, more things are possible, and instaid of taxing preformance and bandwidth ... actually reduces both which make this feature much much more attractive for both resident and linden alike because as a result, people have more resources to create and sell things, and lindens have more resouces to distribute and build their world, which means more money for both parties because of new residents/ reduced cost for running servers /and more room for new residents.
wouldnt it make everything more efficient?
the server has to store hundreds of objects in a database, every prim is one line in a database, every object composed of hundreds of linked prims is hundreds of lines on a database (more or less this is the case/ i do not know how the objects are stored in the database or weather the simulator uses a mysql style database) either way this introduces an overhead on the simulator , there will always be a bottleneck there, and i dont think we can do anything about it, but when a simulator has to update lots of objects on a veicle or anything that requires it the sim has to transmit all this to the client ...which in my opinion is inefficient use of bandwidth and server recources, where we could replace an entire complex object or veicle with a simple 1 prim polygon mesh.. collisions? simple: bounding boxes or per poly, how does SL do it now with complicated 30 prim veicle? do the same with a poly object , when you link several prims together and enable physics .. all those objects act as 1 prim , how hard would it be to have all the basic primitive shapes , and have another one called poly mesh or have an option with all primitives where you can edit vertecies individually at least , or take it 1 step further and add all the basic features a 3d program like 3ds max would have like extruding polygons , editing polys or lines or vertecies having 2 primitives and having them boolian subtract, add, multiply, or divide ...obiously im not ^^ever^^ going to expect a feature like that in SL because the developers are so busy fixing bugs in SL ... such a change like being able to edit vertecies on primitives would not be too hard to impliment , just a simulator update and a client update and its done ...
in short with an upgrade like this .. we wont be complaining about prim limits on our parcels anymore , or for a long while , your SL experience is much more optimised and less laggy, and linden labs will be able to afford more simulators to populate this world as their bandwidth requirements dwindle as people begin to migrate to this method, or they could just reap the profits, either way .. with a bit of inititive on the part of the SL development team, this could benifit all of us.
any comments, sugestion, or question is absolutely encouraged and welcome.
no negative or offtopic/ stupid posts or flames please
|
|
Fulano Giles
Registered User
Join date: 28 Nov 2005
Posts: 4
|
Mesh Prims
01-19-2006 05:22
Changing to mesh objects would actually slow down the servers quite a bit. A prim object can be described by a limited number of parameters, location, rotation, cut, etc. In this way you can render several hundred prims in an area without too much lag.
A mesh object on the other hand has to maintain data on each point, including location and data on each point that it is linked to. Now, if it is a very simple object it can be faster than using prims, but if you need to render anything curved the number of points jumps, and you start to really lag out when you try domes.
This is why you can render several hundered prims in an object, but if you get more than a dozen avatars in a plot it starts to slow things down and the av movement gets jumpy (unless you own a massive computer).
On a related note: I would love to see boolean operators added to the prims, being able to create negative prims would greatly expand the usefulness of prims, while only requiring one aditional parameter.
|
|
lyndell Aleixandre
Registered User
Join date: 17 Oct 2005
Posts: 5
|
01-19-2006 05:34
thankyou fulliano that post is exactly the kind of feedback i wanted ... though .. the avatar rendering system is greatly unoptimised i think that said , if you where to render a dome with only primitives ... wouldnt this slow things down some more given a polygon equivelent?
on regard of physics enabled meshes, the slowdown your talking about is attributed to animation updating /updates and avatar attachments slowing things down on the sim therefore requiring massive client updates therefore slowing down the client ... but if you where to use a veicle system , with more polygons than an avatar would typically have it actually is faster than an av itself because of no animations updating the collision mesh. in short it would be faster than an object equivelent of many hundreds of primitives due to the fact that unnessesary polygons wouldnt be rendered
|
|
hErbs Best
Scripting fool
Join date: 14 Mar 2004
Posts: 13
|
well...
01-19-2006 05:38
As I do not have a clue if it would help or not hehe .. I will just say that I will welcome anything to reduce lag  Regarding the prim counts I don't mind the current situations ... lots of games are pay to play, and well .. if you want the prims .. learn crafts or whatever and make the money so you can get higher tiers - In real life you do not get land or building materials for free either .. Guess what I am saying is - I would love to have new building objects, and if they reduce lag sure  Allthough right now if you think about it the real laggy things are not the actual prims: The real lag is textures and listens (as far as I know) .. the listens .. now .. if scripters would unite to get rid of those .. I'd be happy  heh. Everyone with a bling jewelry has a listen PER piece of jewelry! And ok .. particles can be laggy as well, but think about that when you say "bling off" the listen is stil there - hence still listening for your every word to see if it by any chance would be "bling on". And making it channel 1 is not a solution people .... if everybody listens on channel 1 it will still be the same - I mean there's 4 million channels to choose from! ok .. sorry if it was too off-topic 
_____________________
All your avies are belong to us!
|
|
Fulano Giles
Registered User
Join date: 28 Nov 2005
Posts: 4
|
Domes
01-19-2006 05:54
Quote: if you where to render a dome with only primitives ... wouldnt this slow things down some more given a polygon equivelent?
When i said 'dome' I realized that I meant 'spherical'. The number of points nessesary to make a good looking sphere is impressively large, and annoying to get spaced right (I speak from personal experiance, having attempted once to make one manually).
|
|
lyndell Aleixandre
Registered User
Join date: 17 Oct 2005
Posts: 5
|
01-19-2006 07:01
if you are just going to make somthing spherical then the existing tools , like the sphere prim would do scale it chop it up ... but if you need somthing allot more complicated , like for example somthing that would take several primitives to make it then you would err onto the poly tool or check a checkbox on the prim options tab that says poly edit ..
|
|
Zodiakos Absolute
With a a dash of lemon.
Join date: 6 Jun 2005
Posts: 282
|
01-19-2006 07:33
Incidentally, Second Life already implements something like this, just not in the way you expect: the official LL trees.
The trees themselves are polygon meshes which are stored in the static cache which is installed when you download the client, along with such 'unchanging' content such as the avatar mesh. That is why the trees only count as '1 prim' - they are not ever downloaded to the client, as they already exist.
I see absolutely no reason why it would not be possible to extend this system in order to send meshes that people have uploaded to other clients, which would then be stored in the cache. There are probably some practical reasons why LL does not want to implement this kind of thing yet though, including
1.) Standarization of mesh format/UV maps/skins etc. If this was to be implemented, it would probably take a while to figure out how to make it generally available to SL users, in the same way that texture upload and sound upload is available. Animation upload is already kind of chaotic enough, imagine how complete skinned meshes would be.
2.) Bandwidth. Although highly optimized mesh data could probably be sent to the client, and wouldn't take up much more data than a typical 1024x1024 texture or two... imagine if EVERYTHING was made of custom meshes, with textures. It's possible they don't have the infrastructure to manage this yet, or no immediate plan that would make such a thing viable.
3.) Limited use. Although I, and probably a ton of other much more talented 3D modelers could find excellent uses for this, the actual amount of people on SL that would make use of this feature would be very, very small (maybe 1 percent? Less?). At the moment, LL priorities seem to be geared more toward the features that will affect the most people and make the most money in a broad sense, which is understandable from a business point of view (and possibly an immediate survival point of view). In the meantime, prim modeling is still available for everyone, so there is no pressure at all for them to work on this.
So, my prognosis is that it's very unlikely this feature will be added anytime soon.
|
|
Argent Stonecutter
Emergency Mustelid
Join date: 20 Sep 2005
Posts: 20,263
|
01-19-2006 10:21
From: Zodiakos Absolute The trees themselves are polygon meshes which are stored in the static cache which is installed when you download the client, along with such 'unchanging' content such as the avatar mesh. That is why the trees only count as '1 prim' - they are not ever downloaded to the client, as they already exist. They're actually a recursive fractal algorithm for generating the tree, based on those meshes, plus some static textures for rendering the trees when you're far enough away from them. I just wish you could call llTreeSystem([TREE_TRUNK_TEXTURE,"...",TREE_BRANCH_TEXTURE,"...",...]); and create your own "Linden Trees". It wouldn't be any more expensive than downloading a prim with a particle system and some textures on. LOTS of people could use and benefit from that, without having to define a general mesh format.
|
|
lyndell Aleixandre
Registered User
Join date: 17 Oct 2005
Posts: 5
|
01-19-2006 22:07
From: Zodiakos Absolute Incidentally, Second Life already implements something like this, just not in the way you expect: the official LL trees.
The trees themselves are polygon meshes which are stored in the static cache which is installed when you download the client, along with such 'unchanging' content such as the avatar mesh. That is why the trees only count as '1 prim' - they are not ever downloaded to the client, as they already exist.
I see absolutely no reason why it would not be possible to extend this system in order to send meshes that people have uploaded to other clients, which would then be stored in the cache. There are probably some practical reasons why LL does not want to implement this kind of thing yet though, including
1.) Standarization of mesh format/UV maps/skins etc. If this was to be implemented, it would probably take a while to figure out how to make it generally available to SL users, in the same way that texture upload and sound upload is available. Animation upload is already kind of chaotic enough, imagine how complete skinned meshes would be.
2.) Bandwidth. Although highly optimized mesh data could probably be sent to the client, and wouldn't take up much more data than a typical 1024x1024 texture or two... imagine if EVERYTHING was made of custom meshes, with textures. It's possible they don't have the infrastructure to manage this yet, or no immediate plan that would make such a thing viable.
3.) Limited use. Although I, and probably a ton of other much more talented 3D modelers could find excellent uses for this, the actual amount of people on SL that would make use of this feature would be very, very small (maybe 1 percent? Less?). At the moment, LL priorities seem to be geared more toward the features that will affect the most people and make the most money in a broad sense, which is understandable from a business point of view (and possibly an immediate survival point of view). In the meantime, prim modeling is still available for everyone, so there is no pressure at all for them to work on this.
So, my prognosis is that it's very unlikely this feature will be added anytime soon. thankyou zodiakos for your reply however objects like spheres have their texture uv just like every other object and this shouldnt change for poly objects either, SL already has a feature where you can edit the texture of individual faces, such should be the case of poly objects as well, from what i can see in your post (and correct me if im wrong) is that: trees = static mesthes installed in client 1. poly meshes = too many parameters to be transmitted efficiently 2. poly meshes = no one wants them so why would you go through the trouble of implimenting them 3. poly meshes = logistical problems , in storing and transmiting to client for display by the rendering engine + 1 and 2 the reality here is that if given the chance people realise the possibilities of such a mesh, lots and LOTS of people would use it , if the tool was made easy enough for even newbies to use i would be even better , even so newbies can fall back on the existing prim system also the infrastructure to support this new type of object is already there in the client renderer as the renderer already renders poly objects such an implimmentation client side would not be so hard server side i dont see how poly objects cant be transmitted like normal objects , i spoke to a linden and he told me that the rendering engine cannot handle complicated shapes anyways so meshes that would hold parameter information equivelent to a 1024x1024 texture would simply not be possibly anyways, nevertheless this tool still would have legitimate use as even if you have to make 5 or 6 poly primitives to define a given object its still much much better than 50 or 60 that said .. the database size nessesary to house a given 50 or 60 prim object is much much larger than 3 or 4 poly meshes linked together, as i know from experience that poly meshes are highly compressable for example .. a very complicated quake 3 mesh of over 2500 vertecies and animation information would take little over 320kb moderately compressed ... since the SL engine wouldnt handle shapes as complicated as this for several reasons .. we can have mesh objects that transmit over the socket pipe for less than 5 or 2 kb each as oposed to a 30 or 40 prim object which takes maybe 1 or 2 seconds to transmit over the pipe and be rendered, not a big modification to the sim codebase would be needed to support this. that you said that 1000 out of 100,000 people would use this? i think not , you dont have to be a talented 3d artist to make use of a tool like this, this would allow to make your own custom primitives, to knock back such a proposal is absurd though i do understand your doubts to this, in this case i know for a fact that it is very possible to do, right now we really need to encourage somthing like this and give it as much attention as possible. thankyou very much for your input though it is much apreciated.
|