# Psistorm Ikura

Resident

127

1. ## Problem regarding rotational conversion

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. ## ANS for Direct Delivery

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. ## Rigging in 3d studio max

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. ## Rigging in 3d studio max

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. ## Rigging in 3d studio max

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. ## Suggestions for a post-3.2, working UI

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.

8. ## Viewer 3.2.0 beta - Grats on the UI

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. ## A Draft on a new SL concept evolved from landmarks - Places/Locations

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

11. ## Viewer 2.8.. FIrst impression

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. ## Feeling better...

sounds good to me, thanks for sharing that insight. thatll prove handy when i make rezables (furniture and whatnot) for mesh
13. ## Feeling better...

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. ## The Death of Mesh

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. ## How many of us are really actively build and testing mesh?

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. ## Break Legacy Content!

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. ## One metric is not enough

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. ## A draft to end PEwt discussions: The resource point system.

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. ## A draft to end PEwt discussions: The resource point system.

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. ## A draft to end PEwt discussions: The resource point system.

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.

22. ## A draft to end PEwt discussions: The resource point system.

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.