Jump to content

Psistorm Ikura

Resident
  • Content Count

    127
  • Joined

  • Last visited

Everything posted by Psistorm Ikura

  1. Hello LSL scripting forum. I recently ran into a math issue that for some reason, I can not figure out for the life of me, but perhaps it is a very simple one. First, let me explain what I am looking to create: The plan is to make an object which moves as a vehicle, and turns via llRotLookAt(), and checks what is infront of itself via llCastray(). To simplify the model, I wanted to treat the direction the vehicle is facing as an angle around the world Z axis, aka a simple top-down view. Thus, I am using llAxisAngle2Rot() to cast a ray in a certain direction, as well as to rotate the object in a certain rotation. I should also mention, for the purpose of llRotLookat() to work at all, the object is rotated so the local Z axis points forward now, and positive X points down (as per the criteria of llRotLookat()'s orientation). The problem begins when i want to make the object turn away a certain angle from obstacles to try and navigate around them. At some point, I need to know the current angle of the object around its Z axis and properly modify it. But try as I might, the math I try only produces garbage at worst, and random results at best. For the purpose of easier troubleshooting, I created a tiny script to experiment in. I rotated a prim 90° around it's Y axis - like the "vehicle" I am creating, and dropped in this short script: default { touch_start(integer total_number) { vector vec = <0, 0, 1> * llGetRot(); float angle = llAtan2(vec.x, vec.y) * RAD_TO_DEG; llOwnerSay((string)angle); vector pos = llGetPos() + (<2, 0, 0> * llAxisAngle2Rot(<0, 0, 1>, angle * DEG_TO_RAD)); llRezObject("target", pos, ZERO_VECTOR, ZERO_ROTATION, 0); } } This is as close as I have gotten to a working script. It works for some facings, but not for others, putting it on a seemingly random offset of either 45, 90, or 180 degrees to where the prim's local Z axis is pointing. I know I must be making some mistake as far as either the obtaining or setting of the angle goes, but I can not for the life of me figure out what. Anyone willing to offer some insight is welcome, my web research so far hasn't yielded anything useful. FYI, the object target is just a small object used as marker in relation to where the original prim's local Z axis should be pointing at. The goal is to correctly rez the object at the correct angle of the prim`s world Z axis, regardless of all axis' orientations. Aka treat the prim as if it only had a top-down 2D existance, nothing else.
  2. I don't mind static URL support, after all I run a web-centric vendor solution. But I can't migrate to direct delivery yet, simply because I promise free updates to my customers, and to do that, I rely on a SQL database. So without ANS I can't add their entry to the DB, and thus can't give them free updates. So until ANS is working, I won't be able to switch to direct delivery at all. On a side note: What is with listng images being broken across the board? About a quarter of my listings has a wrong image now, what gives? I saw no notice/news/forum posts about this. Do I need to replace them manually, or is LL working on something / would the images just get re-broken if I did?
  3. Hmm. I will have to look into that again. My utilities tab only contains "Reset XForm", which i have to apply to objects individually, its no scene wide thing. I take you mean that one? Also, my display/system units are set to meters, and if I generate the model at a 1.0 scale with SLAV, it shows up correctly. But the export is 10x the size. So a 0.1 creation scale will get the correct results in SL. Which is strange, since the bone scales - i checked - are 100% whether I create at 1.0 or 0.1 scale in SLAV. I cant shake the feeling that I'm missing something. I mean right now i can rig and export at the right scale, so it works. Just working in max at such a small scale is a bit inconvenient with the camera near clip plane. In any case, thanks for the help so far, you really did save that project
  4. Well, I tried to follow Daniel´s guide, which was very helpful in figuring out some of the WTFs that i had to deal with (like manually editing the .DAE file. i wouldve never guessed that on my own). Status right now is, the rig imports, but in a weird way. I set the units to metric, and created a SLAV skeleton at 1.0 scale. I resized the model to fit, and did a reset xform on it. Did the skin setup, and it imports at a normal size. well. unless I attach it. Then it inflates its size, and due to that, the bone weights act weirdly and it breaks. I've tried various unit setups, but the only thing that does, is make the mesh itself smaller or bigger inworld, but once i attach it, it is always the same, wrong size, and can not be scaled either. I would really appreciate some help here, Im completely stumbling around now and dont have a clue what to do next. Edit: I attempted a 0.1 scale on the skeleton and that seemed to have done the trick. The scale appears to be more correct now at least Edit2: Working at a skeleton scale of 0.1 does work. However: It makes the job pretty annoying, since everything is so small, the near clip plane is a constant issue. If there is a way of reasonably working at a 1.0 scale, please do let me know. Also, display and system units are set to 1 meter, and I am using 3dsmax 2011 and the 1.0.4 SLAV plugin.
  5. I'm using 3d studio max 2011 for my creative work (license holder incase you wonder, i saved up for it), and am currently working with rigged mesh objects. Problem is, im lacking a bit of practice with rigging in max, i know the fundamentals, but I know next to nothing about what is a legit way of getting an export to SL. Right now i got myself an SL avatar skeleton and am trying to use the Skin modifier, but its not very cooperative and cumbersome to use. Ive seen that there is also biped + physique, but im not sure if SL supports imports done that way. If someone has any experience or resources as to skinning/exporting from 3dsmax to SL, id greatly appreciate that and would give them a thorough read. Thanks in advance, and cheers!
  6. Well, they hired "Big Spaceship"; apparently a renowned UI design company. 2.0 was the result, which, even though it now is a good viewer, used to be really rough around the edges and plain bad. What LL needs to do is actually listen in more to the community, and - sorry to say it - listen to the right people. Giving us the option to have things either way imho is the way to go. Not force someone into sidebar usage, but also not force people into floater usage. There are things that work better for some people than they do for others, and vice versa. This is why we need full customizeability. Like someone said above. The changes I hate - the floating chat bar and lack of sidebar consistency - they love. Personally I found the IM icons absolutely space efficient. I can IM AND follow local chat at the same time now, a concept that was alien in 1.23 unless you wanted to have two massive chat windows open, stacked ontop of eachother. V2´s instant messaging is much more advanced, and personally I can deal with large IMs a lot better than I could in 1.23. Again, this is why we need change. And give constructive feedback. Let us have the option to use the UI in whatever way we deem best, trying to enforce anything on the users is pretty bad. It should be easily skinable, and should be coherent, thats the only real requirements a UI should fulfil for SL. Aside from that, it should just be flexible to the point of us being able to make it look the way we want.
  7. First of all, let me say that LL has made some interesting steps with 3.2, back to the 1.x style of buttons and floaters. Now let me also say that I feel that 3.2 should not have been released. At all. Because what does 3.2 do? It turns the sidebar into configurable buttons and merges the few basic mode additions in. It however, tries to turn things like the friend menu, optimized for a tall, vertical space, into a near quadratic floater. this is bad. It also turns away from a design method - the sidebar - which has been around for months since 2.0 got released. Again, bad. It also moves UI elements around and destroys - imho - things that were good about the v2.0 design. once more, bad. What should be done different? Let me say im very much in favor of the idea of configurable buttons, and lots of screen space, but some essentials are lacking here, and lacking bad. Window docking. Why isnt this in? 1.23 didnt have it. 2.x had the sidebar. 3.2 doesnt have it again. I would like to keep the sidebar-like behaviour personally, and would like the option for my floaters to always dock on one side of the screen if desired, when the button is pressed to make them show. Have the viewer remember those preferences for me. Docking the friend/group list etc would be very nice and simplifies things for me.Dividers in the button bars. Why arent those in? Let us place divider spaces to better organize buttons into themed groups.The local chat. Oh god what the hell. 2.x´s chat docked into the bottom bar and was very low profile. 3.2´s chat is... a floater with chatbar and chat window merged into some weird amalgamation that can not be seperated. Please for the love of pete give us the option to dock the chat into the bottom bar. just the bar, no frills, just like it was in V2. bar and up/down button for local chat window.Nothing was really changed. You merged the avatar selector - ill get to that in a moment - and you made buttons configurable. Thats the glorious UI revamp that was talked about. You havent even touched the sidebar-to-floater design change at all. you just made the sidebar windows into badly crushed floaters. The build menu still is cluttered and very filled. Feature-richness is good, but this needs tidying up. If you want floaters badly, optimize them for space. And again, let us dock windows.The avatar selector. I know this is for newbies to select their basic avatar. But sit with me a moment, LL, and think about how fricken awesome itd be if I could use it to instead manage my outfits. I could visually see what my outfit looks like and switch to it. I think generating thumbnails when saving an outfit wouldnt be hard to do automatically, and really, itd increase the use people could get out of the avatar selector. Give us an option to dump the standard LL selections and instead bring up our own gallery of avatars.Mini location bar and "address bar". Ok, i will be honest. The address bar is imho the single most useless thing ive seen. Sorry to be so blunt, but for me, I wont ever type in a second life location, SLURL works just fine. I just dont need anything taking up about 10% of my screen height just so i can see my current location in big letters and perhaps move elsewhere a tiny bit faster. I would much rather keep it optional like it is now, or work on a better, more compact way of handling landmarks. As for the mini location bar, please put it inside the menu bar. You can collapse the information shown in it if there is not enough room, with a mouseover showing the full name. So you would have your (I) button, your parcel flags, then the sim/parcel name and coordinates. If its too long, you truncate the parcel name string with a mouseover tooltip. Frees up precious screenspace, and removes that little sticking out bar. 1.23 did it, 2.x should do it too!Please leave us the option to select which corner the notification menu docks at. Top right, for me, is unintuitive and cumbersome compared to the previous location. Just leave us a choice here too, follow through on your maxime of customizeability.So how would I sum this up? Basically the idea is to give us the maximum amount of customizeability. Let us configure the UI exactly how we want it. Someone wants a more 1.x based look? Sure. Someone wants floaters and to dock some things into the sidebar? Sure. And someone wants 2.x styled sidebar-like goodness? Sure! Dont just throw arrangeable buttons at us, which are really the most minor feature UI wise, then force floaters back on those who got used to the sidebar. Let us actually have a choice. Dont try and pull a "dazzle" on us two or three times in a row, introducing harsh interface changes without going the easy route, namely just letting us custuomize it. Ive worked with SL for years, and earn my salary exclusively here. SL has great potential, but the UI as it stands with 3.2 needs more work. Just hold off on 3.3 or 3.4 and instead, do it right. Release a complete, finished concept, which allows your users to pick a 1.x, 2.x, or whatever style they want. Sidebar-floaters, docked windows, floating windows, docking chat, docking IM´s and notifications to different corners... there is so much potential, use it!
  8. I've seen the review of it, and like it. The customizeable buttons are much welcome, but the chat bar seems a bit clumsy, and I would prefer if we could, say, dock windows to the sides as an option. Tidying up the windows themselves will certainly be a good thing. That aside, I'd also like the option to: - collapse the mini location bar INTO the top bar if there is room - have notifications on the bottom right OR flexibly in either corner of the screen really, for maximum customizability That aside, its looking great so far, and lightweight
  9. I wouldnt want that to happen either. I would suggest teleport as default double-click action. Maybe once you hit "profile" or whatever the menu item was, it takes you to the web-end of this club, much like an avatar profile. Thatd fix the spammyness, because really, there wouldnt be any sense to enforce teleports via the web profile rather than directly
  10. Let me start off with a brief discussion about how we access certain places on the grid currently. Typically you use a landmark, which is nothing more than a region name and some coordinates with a name and picture tacked on. Sometimes we also access these things via classifieds and via search. And also quite often, people move, venues or entire sims move or close down for good or only just for a while. This means you have a lot of landmarks which might say "Club Awesome" from 3 months ago, but if you use them, you end up in a river, or in someones living room all of a sudden. This, among other beneficial reasons, is why i thought about suggesting a new type of asset, the landmark evolved, so to speak. It could be called a "location" or a "place", simply. Now how would it work out? What would it do? Places would be different from the general concept of SL assets. Once an SL asset is up there and distributed, the original creator cant influence other copies anymore. A place would be different. It would consist of a name, picture, description, and most importantly, a VARIABLE destination. So that your "Club Awesome" landmark would always take you to Club Awesome for as long as it existed. Now for some details. How would you go about creating such a place? First and foremost, my thought was to require admin rights to a parcel, so you actually own a place. From there, you may create a Place from this piece of land. It can be set to be a classified, and you get the appropriate item in your inventory after setting it up. Now, you may distribute it much like a landmark, with one big difference: Any changes you make to your place are reflected in everyone´s inventory, meaning there is only one asset that is referenced to. The name, the description, the picture, the coordinates/region you are pointed to. It can all change. This lets you assign your venues such as stores or clubs to something that will never be outdated and always bring your customers where you want them to. Now lets say you move. What do you do? You open up the parcel settings and assign the place item you own to this new parcel, and within a few moments, people are able to find the new location. And what about cases where a location closes down, or moves and is temporarily without a location? My idea would be different status conditions for it. Either Open (default), Closed down (for when you shut down your venue, which would display a warning text upon double click, so people know they may delete this now), and Under Construction (or some such. this would be for when you move and dont have a new parcel yet, or your new parcel isnt ready yet for public use. This could display a special custom message upon activation). The system is expandable, too. For instance, you could hook a group up to this place, and LL could offer a profile much like a normal persons social web profile. Perhaps a premium user could get access to picture and forum space. This profile could house a calender, staff list, a marketplace integration to let people see your latest offers. The calender could schedule events and new product releases and such, adding tremendously to the functionality of it all. So what are the benefits I see in this? A universal "landmark" which doesnt get outdated anymoreLess inventory clutter from outdated landmarksWith the suggested expansions, you can create micro social networks within SL revolving around a persistant local identity. You can create a venue that feels more persistant, more like a social focus point than just a place on the gridLocation independency. Do you really care what region your club/store is in? Probably not. Should it get in your way triyng to visit it? Definitely not.An extra incentive for premium accounts, since premium locations may offer extended services via the web profile options.I woud like to hear some thoughts on this, criticism is very welcome, as well as other ideas. Just keep to the topic please, and have a serious discussion :)
  11. I tested it out. I still get the friendlist glitch, but at least a fix for that is definitely planned with the Magnum RC regions, which I will test once its rolled out. Aside from that, the new profiles I do like, though instead of "feed", the "about me" page should be open by default when opening profiles. At least for non-friends, thats the more relevant page to open. Also, shadows work and look nice, but lordy does my graphics card spin up. when its sitting in comfortable idle mode at 60fps with deferred off in firestorm 2.5.2, its howling like a banshee at 30 fps with shadows on in 2.8. Its only a minor thing, but i wonder if there isnt more tweaking to be done in that respect. Just feels like there might be, but could be me
  12. sounds good to me, thanks for sharing that insight. thatll prove handy when i make rezables (furniture and whatnot) for mesh
  13. if those numbers are true across the board, thatd be wonderful. Then only a good balance for very large mesh objects needs to be found and we should be golden. Im looking forward to seeing more reports, and especially how close to where LL wants things to be those numbers are!
  14. I think that marketing prims instead of land would be nice (within certain limits to prevent rich people from totally bogging down sim resources and ruining the experience for others), but I see a wholly different problem with high mesh PE: the density of parcels with mesh builds would simply bottom out. Take the small 134 prim tree mentioned earlier. It could hardly fit on a 512, rendering it pretty much empty. So if you want anything at all on your land, you have to use prims and sculpts. If you do NOT want anything at all on your parcel, no matter how big, use mesh.
  15. I have been doing small scale testing in the early days of the beta. After mesh client version exceeded 2.5.x though, i was no longer able to see the grid, since my friendlist and teleports instantly failed upon logging onto beta, and absolutely nothing rezed. I couldnt see uploaded meshes, only some avatars rezed after a while. The problem also persists with most official viewers on the main grid atm, but 2.4.0 or firestorm can connect without issue. just 2.7.2 and such show the error. And since there are no alternate mesh-beta viewers i know of, Im officially locked out of further testing. JIRA has been filed long ago and a fix is being deployed soon apparently, but not for the beta grid, that i know of.
  16. Drongle McMahon wrote: "without generating noteworthy advantages." The noteworthy advantage that "meshies" would have generated if mesh had not been poisoned with selective peanalties would be similar things having 1/20 the triangle count, thus 1/20 the rendering burden, of the same content made with sculpties and prims. This would have greatly improved the performance of low-end machines. As it is, everyone will continue to make the same gpu-crippling stuff they do now. In fact it will be substantiall worse because, just like meshes, the 10-64m sculpties and prims will stay at high LOD over huge distances, but unlike meshes, they will not be penalised for the extra burden. this. there is nothing else to add, i just wanted to emphasize this post again for how true it is, and kudos to you drongle, for summing it up so well. Regarding the topic: Ive suggested a system to that extent myself, with a transitional phase which would allow people to adjust their stuff. Though lets face it. certain objects would very much be broken. BUT those objects would/should be things like: buckle boots where every buckle, nay even the little holes for the shoelaces are modeled out of sculpts or torii little earrings or other jewelery items fashioned out of 50 prims or more sculpted hair with a color change script, which happens to be existing in every prim, rather than using llSetLinkColor() or other useful functions builds where every last detail is modeled out with torii instead of using sculpt or mesh to achieve the same look with a LOT less triangle density, and also a lot less physics complexity etc. Builds like the above examples really are unnessecary and waste sim resources. Maybe not everyone has the skill to do it efficently. But lets face it. Secondlife lets you build wasteful right now, and there are NO hints or ramifications besides a rather un-noticeable ARC value, which is hard to interpret anyways. SL needs to make a user aware that jamming 50 torii together and wearing that as a necklace along with an avatar filled with those things will impact server and client performance. They shouldnt draconically limit everything, but there needs to be a certain treshold of things that really shouldnt exist. Which brings the mesh debate up again. Mesh could do just that, allow for modeled detail without going overboard, if executed sensibly. But right now this isnt done, neither is an overarcing content measurement system planned, either.
  17. The concern is clearly valid, but to avoid this, a transition period would have to be introduced. A period where the viewer gets the necessary updates, but they are simply "for show" for maybe 3 months or something. This would mean residents could see how much resources they are using under the new metric, and address potential issues that arise. Only at the end of the transition would these metrics actually take effect and stuff be returned that was over the limitations. That said, the idea of a more spread-out metric is interesting, and would certainly allow for a fine balance of how many resources of a kind LL wants to run on a sim. On the other hand, it will be a challenge to divvy up those ratios responsibly, so that, say, textures dont get too much or too little space assigned, or mesh, etc. The benefit with the single-metric system of mine is taht it is adaptive. It could be either a low-prim, texture intense build, or a high detail, but lower texture build. But this, on the downside, is putting server load somewhat on the same level for all asset types, unless their costs are balanced to match. Which they should be, mind you. As the person who opened the single metric post, I´m favoring mine, but I´m biased, obviously. But I will say that the OP´s, given a good, easy to understand implementation, certainly has a lot of merit and is as good a solution as my own, thinking about it. I think we can agree that a new metric is needed for all this though, rather than trying to obscurely define mesh costs via PEwts, which are hard to understand for new residents. That, and the case of "the whole is 32.000 times greater than the sum of its parts" needs to be dealt with desperately.
  18. Ill have to agree with the other Vivienne, in that this isnt a real answer. It is certainly nice that you work with professional modelers, but your attitude is becoming condescending and mildly offensive in my eyes. So with that, please cease this discussion now, for it is not only starting to derail in itself, it also has no connection to the nature of this topic. If you have issues with how LL handles mesh, then please take those to a topic created for that purpose. This is about creating a complexity/cost modeling system for SL´s future, not some quarrel about the subject of mesh in general, please respect that and cease further attempts to steer this off topic.
  19. 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.
  20. 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.
  21. 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: http://community.secondlife.com/t5/Mesh/A-draft-to-end-PEwt-discussions-The-resource-point-system/td-p/945759 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.
  22. 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.
  23. 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 linksetAmount and size of unique, streamed (meaning non-standard, not-in-viewer-installation) texturesAmount of scripts OR size of allocated script memory past a defined (64-128kb) tresholdSecondary properties, whether the object is a light, flexible, or physical, phantom or other such thingsDiscounts 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 purposeThe 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.
  24. 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.
  25. 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)
×
×
  • Create New...