Psistorm Voxel
-
Posts
134 -
Joined
-
Last visited
Content Type
Forums
Blogs
Knowledge Base
Posts posted by Psistorm Voxel
-
-
Vivienne, I think you are misunderstanding the point we are trying to make here. Noone here is encouraging or endorsing 100.000 triangle wristwatches or other such abominations. And we do want a system which makes those meshes expensive to have in world. That is the core thought between the resource point system and the resource coefficient. Let me sum it up:
- The resource point system replaces the prim count system. Meaning if you want to import this ultra detailed mesh, it will cost you. If you want to put a 1024 texture on every face, it will cost you too.
- On the OTHER hand, not only should it discourage misuse, it should also REWARD if you actually build something good. Lets assume you could build an object out of 4 sculpts, aka 4096 vertices. Or you build the same object much more efficiently out of, say, 2000 verts as a mesh object. The mesh should be cheaper here, and rated better.
- The "resource coefficient" factor I introduced should serve as an indication of how complex an object is for its given size. So everyone can tell at a glance that "oh snap, this object really is a complex abomination. Im not buying this"
I hope this serves to end your complaints about the system itself. No one here is a perfect modeler. But the system should be designed to both discourage mis-use, and encourage efficiency. In Linden Lab´s proposed state, really it discourages using mesh at all, no matter how good you are at using it.
And to touch on the subject of game content being ripped and posted on SL - this is why you have to have "payment info on file" to upload mesh content. This way, they can actually block you from further copyright infringements. Unless you really want to keep registering new paypal or credit card accounts, that is. But I would say thats a bit much hassle. Plus there is always MAC or IP bans for repeat offenders.
-
I fully agree with Drongle. There are just too many volatile cases here where linking two objects together suddenly creates something that is greater than the sum of its parts. I do NOT want to live in the constant fear of having my home be returned to me just because I link a 100 triangle mesh to it and that caused the entire thing to go haywire.
I would like to direct you, Nyx, to the thread i posted lately to address some of these concerns - not all of them, but i certainly tried - and see your opinion:
Yes i know its a bit of a plug, but i would love some linden feedbakc on what I think is a good idea. On the issue of builds being returned specifically i would like to suggest to make a "is parcel full?" check BEFORE executing the link. So that if you do one of those volatile linking operations, the viewer blocks you from it with a warning, rather than returning your house or whatnot without warning.
Edit: I would like to go a little further on the issue of this topic and say the following: In light of usability, and the "your world, your imagination" phrase that seems to be SL´s guideline in design, i believe that the mere idea of a linkset being 1000x heavier weight - or a different weight at all - than the sum of its parts is indiscutable and should be discarded.
There have to be solutions to fix the sudden explosion of physics complexity, and there has to be a way to create a transition to an all-encompassing, easier to understand system if you decide to add these weightings. I again briefly point to my suggestions above to the nature of the system, but for the problem at hand, my stance remains. Just because you link two things one way or another, their cost should NOT, never ever differ.
-
I think the suggestions you make are mostly covered with how i would want this system to work. Most notably an additive nature, and a straightforward, easy to understand system that illustrates how many resources a certain object will cost.
As for the mention of meshes only having a doubled script count when the server cost is overriding - I think we can both agree that this is not something the end user should have to bother with. A builder wont undertand PEwts, they wont understand streaming or server cost, and they certainly wont grasp why their little mesh is double the primcount all of a sudden. Hence why i introduced this linear system.
On the nature of a size scaling factor: Ive tackled this question via the resource coefficient. I believe an object should cost the same whether it is 10m or 60m in size. The streaming weight is the same. The server cost, save for physics calculations, is mostly the same. Rendering should not be all that different either. Thus, the resource cost should not scale with size. What however does scale with size is the coefficient. This means a complex, small object has a worth, say, efficiency rating than the same object enlarged. This keeps large scale builds viable. So if you want to have, say, a large skyship, you can do this, as long as you dont go overboard with complexity.However the final word on this isnt spoken, given that a 10m object versus a 60m object of the same shape may have considerable diferences in rendering cost and physics cost that I dont know about right now. This is why i would like linden feedback.
On the subject of texture and mesh/sculpt reuse: This is hard to judge indeed, since the re-use is very much dynamic. Think of a bunch of popular anthro avatars gathering in a common place. You will see a lot of re-used sculpts for same species avatars, for the duration of the event. After said event, the re-use is gone. Thus, since this really is impossible to predict, and since per-minute dynamic resource cost numbers are out of the question - they should be static and reliable - I would say that the average asset re-use should be taken into consideration when balancing the individual costs for object components in the first place.
-
After giving much thought to the ongoing debates of prim equivalency, streaming weight, server weight and all these complex schemes, I did develop an idea of a system which may actually provide a solution. Allow me to explain my thoughts in greater lengths here.
Problem
Linden lab seems to want to curtail excessive resource usage, and more efficiently model the actual load that certain builds have on the server. Right now, they attempt to force these new weights on mesh objects, and mesh objects alone, the entire process seems a bit convoluted, since people dont exactly know what the plan is. It is all very much in flux. The current implementation, if it goes through as planned, creates the following issues:
- Mesh objects were understood by the community to be a new, shining future of efficient and prettyful builds. Actual 3d modeling in a virtual world, tremendous possibilities. These hopes are now sorely dampened.
- Meshes are laden with so many restrictions that it seems impossible to make a build that looks equivalent to a prim or sculpt build, and have it cost less than said build, even though the prim/sculpt build is a lot heavier on the renderer and other resources, due to the skewed weighting.
- Scripted meshes arent viable anymore due to the harsh doubling of prim costs currently introduced on mesh objects.
- Linking prim and mesh objects makes the linkset subject entirely to the new weighting system, thus creating more confusion among beginner builders than anything.
- Since prims and sculpts currently remain under the old system - and apparently are remaining for a while yet - this encourages people to further ignore any benefits mesh could - but currently does not - offer and continue to build in less efficient ways.
Solution
The idea of integrating the actual load of a build into a single, easy to grasp figure has been attempted with the ARC measurement, although poorly in some cases. I suggest not pursuing this idea further, since it mostly models client-side render cost. I want to introduce a new system instead, evolved from the prim count measurements that currenty are the deciding factor of build complexity.
The resource point system.
This system is what it says on the label. Instead of measuring prim count, or worse, prim equivalency (what a long, ugly word for people who just want to build and have fun), it measures the resource cost. Resources are a common term. Whether it comes from strategy games, or the everyday work experience (HR anyone?), it is a term we are familiar with. We know what it means, what it stands for, what its defining characteristics are.
Resource points are to replace prim counts throughout the grid over a sufficiently long adjustment period (more on this later), and will encompass the following measurements:
- Amount of primitives, sculpt and mesh objects (weighted by complexity) in a linkset
- Amount and size of unique, streamed (meaning non-standard, not-in-viewer-installation) textures
- Amount of scripts OR size of allocated script memory past a defined (64-128kb) treshold
- Secondary properties, whether the object is a light, flexible, or physical, phantom or other such things
- Discounts apply where applicable. Repeated use of mesh or sculpt objects in a linkset makes it easier to render, and lowers its proportional streaming cost. Likewise, phantom objects do not create a physics load. This should be honored.
These factors are added together to determine a resource cost number for a defined linkset. This number is NOT rounded but rather allows a single decimal point, for a weighting that is as fair as possible.
However, this creates one followup problem: How can we balance this system against current land prim costs?
My suggestion to this is as follows: Simplify the prim count system when switching over to the new resource point system. Lets assume the easiest way. One square meter of SL land will allow for 10 resource points. This will make resource point measurements for new residents easy to guess. You wont have to struggle with arbitrary numbers (even I cant remember how many prims a 512 parcel holds. Its a weird number), but instead, are able to derive the resource capacity of a parcel at first glance (bonus factors witholding, i would like to keep this mechanic).This means a 512 parcel will have 5120 resource points available to spend. A 1024 will have 10240. This measurement is easy and simple. On a sidenote: a parcel with 512 size and up is eligible for rounding down of decimal costs. So if your overall prim cost is 5120.9, it will still fit on your parcel. This allows a fair, small and non-exploitable buffer zone for parcels, which should not noticeably affect server performance in any way.
The marketplace and the resource coefficient
The Second Life Marketplace has become a large part of the SL experience. As such, it will require special treatment as well. The questions here are the following:
- How to make residents aware of the resource point system and its importance?
- How to give an idea to people of how complex and/or efficient a build has been completed?
To these questions, two solutions are presented:
- When listing an item on the marketplace, the final goal is to make it a mandatory field to publis the resource point cost, as well as the newly introduced resource coefficient (name not final)
- The introduction of the resource coefficient. This factor is a simple, straightforward measurement of how complex a build is for its size. Imagine an aqueduct, 100 meters long, with 5 1024 textures and maybe two scripts, meshed out of 20.000 vertices. This would yield a rather low coefficient, which is good. Now imagine a car, with the same specifics, 3 meters long and appropriately proportioned. The coefficient here would be very high, indicating that for its size, it is a very complex object.
Secondary considerations: Scripts
Scirpts certainly do play a large part in this as well, thus for this system to truly work in a fair way, a few technological changes are needed:
- Variable script memory. This is a big one. Should a door script take up 64k of memory? I dont think so. it might do with 2-4k. Should I be forced to create a second 64k script with overhead and double the codebase, because dynamic data storage drives the peak usage to 70k? Again, i dont think so. These examples are why variable per-script memory is a good idea.
- Parcel-based script and script memory limits. Again, quite a big one, since it prevents people exploiting the "free 64-128k memory per linkset" idea by creating single-prim objects with scripts in them. These limits should be within the expected borders of current peak script usage, and will be subject to discussion.
Implementation
A system change this noticeable will need preparation and information. My suggestion is as follows:
- First roll-out of new sims/viewers on beta grid with the new mechanic in place as a for-show system only. Resource points are in the UI, but only illustrate the costs of builds on the new system. This is to find a balance that both residents and Linden Lab can agree on being fair and feasible. Furthermore, the build menu is restructured to allow for complete and easy resource analyzation, to answer questions of the nature of "how much resources does this prim eat?" "how many resources does my script take up?" etc.
- A public beta on the main grid. Again, the system is for show, to verify the fairness of the resource system. Final tweaks to weighting of certain components may be completed.
- A transition period of 3 to 6 months. New builds will fall under the new weighting system, newly created prims, uploaded textures, scripts, sculpts and meshes are calculated under the new system. Old builds are grandfathered until the end of this period before being calculated in resource points instead of prims.
- The final transitional phase. The resource point system fully replaces the "prim count" measurement on SL. It becomes mandatory to publish resource cost figures for every item sold on the marketplace, all grandfathered builds are turned over to the resource point system and may be returned if they overfill parcels. There was sufficient warning and information given. At this point, viewers must support this metric to be allowed to connect to the main grid
Benefits
- A fair, easy to understand system to model every aspect of a build into a universal point system. New methods of building may easily be incorporated into this comprehensive model. Also compared to PEwts, this system handles everything. Prim, sculpt, mesh, textures, physics and scripts, and isnt exclusively biased against new and promising technology.
- The amount of resources in relation to the parcel size, bonus multipliers set by sim owners witheld, is easy to understand for anyone.
- Mesh objects may be properly balanced and brought in line with the resource cost on the server as well as the resource cost for the client (render weight) of prims and sculpted objects, thus giving them a purpose
- The resource coefficient metric allows residents to tell how efficient a build is, and it allows shoppers to easily see whether that prim or mesh hair they buy will be a laggy piece of *expletive*, or whether it will be an efficiently modeled piece of beauty. Again, a simple, straightforward, and easy to use mechanic.
- Discounts and other, detailed calculations provide a fair way to tell complexity, and directly reward builders who go the extra mile to make sure their building, texturing and scripting is as perfect as can be. This creates a direct motivation to build efficiently and makes SL a better place.
Closing words
I have put a lot of thought into this post, as the verboseness hopefully shows, to try and highlight what i would like to see introduced, why i would like it, and why I believe it would be a really, REALLY good idea for Linden Lab to create a universal, all-encompassing resource measurement that people both old and new can immediately identify with.
I would enjoy hearing your comments, and I would especially be honored if a linden or two could post their thoughts on this system and its implementations, whether and where they might see issues, and also where they might see benefits and chances.
-
The idea of penalizing a mesh by doubling its cost for even ONE script (which might be as "intense" as opening a door on click every once in a while) is ridiculous.
As suggested in another thread, I can understand that the desire to limit excessive scripting is there. But then introduce a treshold. Lets say a certain number of scripts per prim on average (with a hard cap of say, 16 scripts) act as treshold before the prim cost starts to rise. So if you have a low-prim mesh object with one script in, hey, no problem. If you have a low prim object wit 50 bad scripts in it? problem.
These tresholds arent final, but just a suggestion. Even if that gets shot down, doubling the cost is wrong wrong wrong. A steady, decimal point increase is the way to go here. You are introducing this complex system, yet seem to rely on rounded prim weights. Lets just go decimal, and maybe have a script add +0.1 PEwts to an object. or maybe 0.25 or whatnot. This would, however, be easier to do if you had variable script memory. that way, a small 4kb script could add 0.1PE, whilst a 512kb monster could add a full prim or two. There has to be some gratification for scripting efficiently.
With the current outlook, hardly anyone will bother with mesh, even though it can lower server load. And scripted meshes are dead in the water already by these standards. Enforcing standards to encourage more efficient resource use is good, but these numbers punish everyone, not just the wasteful builders, I´m sorry.
Take my line of work for example. I spent months perfecting a system for adult accessories, so that they use the fewest number of scripts, and not a single prim more than absolutely necessary. If i wanted to use mesh for that, my prim count would suddenly double out of nowhere. If i wasnt working on attachments, and rather say, furniture, i would be upset to say the least, to have my efforts tossed aside like this. Or take a look at my mate´s work. He has spent weeks leraning mesh, creating a nicely detailed, yet efficiently modeled table. It eats a whopping 16 prims, with sculpt torture, it could probably be brought down to 7 to 8. It would have 5 times as much triangle density, but it would still be cheaper. awesome, isnt it, how you encourage efficient building with this system? Sorry for the sarcasm there. I do want to be constructive, but some decisions do baffle me. SL is at the verge of a breakthrough, and it shouldnt end up being a negative one. So reconsider your decisions, imho.
-
It might be that these questions have been answered before, but i couldnt find the answers im afraid. If so, i apologize upfront for asking again, however.
Basically, Im looking for two things, since im starting mesh work myself recently:
- Is there any way to get a fully rigged/skinned SL avatar mesh into 3d studio max? I want to build avatar attachments, and be able to see how they deform along with the av mesh without having to rely on the beta grid (due to a server glitch, the beta grid is unusable for me. no friends, no teleports, nothing at all rezes, ever). That would be a tremendous help and save me tons of work uploading and re-uploading.
- Is it possible to control mesh via scripts? Such as, swap out a mesh fine via a script command, much like a sculpt? This would present large benefits to my line of work (creating an anthro avatar with variable, mesh-based facial expressions rather than having to pummel a sculpt into submission to look like the desired facial features)
-
imho, mesh in general is being butchered, cost wise, when you look right at it. mesh is the only object type that gets more expensive by size, and the only one that gets a cost slapped ontop - doubled even! - of it for containing even a single script.
If a new cost system is needed, then please do balance it better, so that mesh is actually turning out to be viable, without having to completely bend over backward to get close to what a - less efficient - sculpt or prim build would cost. Mesh should be sold as something good, not something hideously expensive, when already, a lot of fears are attached to it (content theft, copyright infringement, horrible performance from people importing 5 million poly poser meshes.. and the like).
If this cost system HAS to be done, then weigh it properly, and dont try and put mesh on the new system whilst prims and sculpts remain on the old. This will destroy mesh retention rates for sure, it certainly will keep me from using it for anything but attachments.
Edit:
If I may think up a general prim weighting system, i have some suggestions here:
- Allow decimal weights. A torus could sit at 1.5 perhaps, maybe even 2, a sculpt could be the same. Decimal prim weights are NOT rounded, but instead are added up to the total sim prim usage. That way, you dont have a prim or mesh rated 1.3 costing 2 on the sim. so a mesh rated 0.7 would still fit.
- A bit more finely scaled weighting. A box costs 1.0, sphere 1.25, torus 1.75 maybe. Sculpt 1.5 or something.
- Fair mesh weighting. Prim weight is based off of physics shape complexity, LOD0 triangle count, and a weighted average of the other LOD`s triangle counts (this should be balanced so that an ultra simple object with only one lower LOD level - due to it otherwise being TOO simple to ffeasibly render - isnt punished massively.)
- Seperate script count limiting system. Script limits do NOT affect build cost, up until a certain treshold. Maybe 16 to 32 scripts, from then on up, a gradual cost factor is introduced into the prims containing those scripts, perhaps 1.0 prim weight for every 8 scripts ontop of it or so. This will allow low scripted builds to remain cheap, and introduces a slow cost-increasing factor for heavily scripted builds. Additional script limitation work can be done via other means, as LL did have plans before the big layoffs, such as variable script memory and such (memory could also be a limiting factor, btw).
-
Another thing i would like to bring up, while talking with Murry Soothsayer (posted above some) the other night, we realized something else:
Re-using the same mesh in a linkset does not offer any bonus to prim costs. It should. Why?
Lets say you build a wing, and create a low-poly mesh feather for it, no alpha maps. With the base cost of 2 prims per mesh minimum, you would end up with, say, two prims for the wing arm, lets say, 200 polies. and each feather, lets go with 50 here, at 20 polies. So for a wing, you could assume 2 meshes that are in memory (and one of which can be subject to geometry instancing if SL supports that, thus drastically reducing render cost), and generally you may also assume 1200 polies for the entire thing.
Now the prim cost? 102 prims. you COULD build the entire thing as sculpts, for 51 prims, and would end up with over 50.000 vertices, i cant be bothered to figure out the polycount atm, but you see my point.
Not only should low-poly meshes cost one prim, but also, once you start linking several of the same mesh into a linkset, there should be discounts applied.
On the other hand, there should be a slightly expontential scaling for meshes which are a small size and go past a certain triangle limit. Especially for physics shape. So if someone creates a 50.000 triangle physical spinning top, it´s cost should be way higher, proportionally, aka a non-linear scaling. Large objects however arent affected by that as much. This is mostly a measure to stop people from creating ultra-detailed small mesh objects, with detail that really isnt needed.
For a current equivalent, think of 100-prim wristwatches with bling. -
Given how thanks to a bug (filed on the JIRA, reportedly with a solution coming soon) I am unable to use the mesh beta grid, i have to go off of what people talk about here on the forums and what little experience i could gather before the bug.
In all honesty, this system is ludicrous, im sorry to say it. Please do name a reason why the following should sound anywhere near right:
A sculpt object with 10 scripts in every prim, say, 4 prims, 4000 verts approximately. Cost? 4 prims.
A mesh object, a single script compared to the 40 above, 1500 verts, proper LOD, physics shape, whatnot. cost? maybe 3 prims, thanks to that ONE script, it costs 6 however.
Punishing meshes for being scripted, and for server weight and whatnot is just not applicable. Mesh costs imho should be based solely of:
- vertex count
- face count (after all, being able to load 7 1024 textures onto a mesh is considerably more resource intense than a single faced mesh with only one texture
- perhaps upload size, which would derive ultmately from vertex count and face definitions, complexity of the UV layout etc
Anything else is moot. Mesh should be designed as a tool to not only bring prettier builds into SL, but also to bring more EFFICIENT builds into SL. If mesh will ALWAYS be costing more prims than a way more wasteful sculpt or prim build, them Im sorry, I wont bother with it either. Why waste prims if I can just slap together some prims for something that looks same-ish, eats WAY more vertices and texture space on the renderer, but costs less prims?
If you only want it useable on avatar attachments, then say so. But at least give us the option to define morph targets (aka blend shapes, whatever you call them) so there is at least SOME justification to bother with it.
-
I do appreciate switching to newer standards where applicable. SSE2 is by no means new or limited only to top end. However im curious as to what the gains from this change will be, for the end user, if there is a measurable effect or further implications.
-
Im using a gtx580, 8 gigs of ram, and a core i7 920 @3ghz. I get solid 60 FPS in my home sim, but it drops to 30ish running shadows. Enabling the DoF effect just makes the GPU go bat**bleep** and i can hear the fan start to howl like crazy.
Imho, the renderer feels poorly optimized still, but im no expert by far. CPU load still is VERY low on multicores, but its nice to see it makes better use of the GPU now. Still, now that the renderer can do per-pixel lighting, they should drop the extra tesselations on prims to bring down the global triangle count of certain builds a fair bit. That is only a small thing, but would still have some effect im quite sure.
I hope that subsequent releases see more of a performance improvement, Im quite certain it can be done with more work put into it. But again, wishful thinking, im not an expert by any means in this field.
That, and i would much like them to optimize their ambient occlusion shader, its quite grainy for me, especially on the water.
-
well, i use a router/DSL modem combination, i dont really have the option to try something else right now.
as for forwarding, the router doesnt support opening, only directly forwarding ports, as far as i could determine. seeing as you say connection issues, i wonder what changed between 2.4.0 to 2.5.0 to cause this sudden loss of functionality for me.
-
Ill try and disable that feature, thanks. and well, it seems to affect any sim really. mesh beta, i log in, see an empty sim with only my character rezed. any attempts to tp out result in logging out.
on the live grid, the sim does rez after a relog usually. i can also log into other sims than my home sim, but generally, teleports will fail. 2.4.0 works flawlessly however, for no discernable reason. on another note, i also tried various cache resets and clean installs, all with the same result. but i will attempt your suggestion and hope
-
Starting with SL viewer 2.5.0 (and mesh beta 2.6.0), I can no longer use:
- my friendlist. everyone either is Unknown or (loading)
- teleports, each attempt will log me out
- scripts in inventory, compile/upload will fail, request timed out
I sit behind a router, which i have configured according to the wiki page on port forwarding, and the problems start as soon as I try to use 2.5.x instead of my current fallback, 2.4.0. Any help in that regard is appreciated, since I want to use the latest viewers.
Please do NOT direct me to TPVs, i do not wish to use them. I wish to make use of 2.5.2 and onward, since it seems to be a problem that started and persisted with every release after 2.5.0.
Ontop of that, I do require the mesh beta viewer, which has the same functional problems. Any help is greatly appreciated.
-
Ive tried Kirsten before, and found the UI changes to be rather horrible. The standard LL viewers have been very good for me, as i said before. It´s just that 2.5.0 started giving me trouble, and i would like hints at how to fix these on my end. It doesnt seem to be the SL servers, since 2.4.0 has none of these issues.
-
Ive been using the 2.x series from the get go, and have been more and more satisfied with its development. However, as much as i appreciate progress, the 2.5.x release series is flat out unusable for me.
Basically, I have one of two issues after installing 2.5.x:
- things will not rez. I see a lot of grey prims, and a lot of unrezed sculpts, but my bandwidth sits at idle levels, just like when everything is loaded in. A viewer restart generally fixes this, but in a new area, this problem repeats itself.
- The friendlist will either show everyone as (loading or as Unknown. This does not go away except in seemingly random conditions. I have tried reinstalling, a cache clear, custom port connection, and forwarding the appropriate ports in my router, according to the SL wiki. once i go back to 2.4.0, my friendlist comes back. upgrade to 2.5.2, and everyone is (loading) again, and I can not IM, teleport, send inventory, etc.
Id appreciate any and all hints in the direction, its rather strange and i couldnt find any reliable information beyond port forwarding, which im already doing.
Facebook
Instagram
Twitter
YouTube
Flickr
A draft to end PEwt discussions: The resource point system.
in Mesh
Posted
My opinion differs. Linden Lab has the full right to block/ban any account infringing on copyright claims. Linden Lab is based in the US, thus subject to US state law, period. Thus, any reports of copyright infringement will be dealt with and the offending account will have their payment info banned from uploading mesh content.
Also, lets please end the discussion of whether mesh is or isnt the devils advocate. This does not belong in a topic targeted at a different problem, and frankly, has been discussed thoroughly before. Mesh is coming, and it wont ruin SL just like voice didnt. If you remember, many people foretold the end of SL when voice would come. Anyways, Id like to stop being sidetracked, and ahve comments about the proposed system rather than the "evil" of mesh itself.