Psistorm Voxel
-
Posts
134 -
Joined
-
Last visited
Content Type
Forums
Blogs
Knowledge Base
Posts posted by Psistorm Voxel
-
-
Ahh that does help. So do I need to add the mbones to the skin modifier at all, or just make sure they are listed in the .dae? Also do I need all the caps bonesto the skin modifier or just the ones I use?
Thanks so much for your help with this by the way. It's been a bit tricky to find out just what exactly was required.
-
Since it's been a while for me since I last built an avatar, I want to do so now, and rig for fitted mesh to get a better quality out of my work. I ran into some problems however while perusing the documentation, since the 3dsmax tutorial still only covers the old skeleton rig and is wildly inaccurate in that regard.
Right now I tried the old workaround by setting the bone count to 26 and replacing the old m* style bones with HEAD, NECK etc (I also rigged exclusively to those in the skin modifier on my model), but SL believes that the model has no skinning information attached to it, so I am doing something wrong, but I don't have the slightest idea what.
So my questions are:
- Which bones do I /actually/ need to rig to in 3dsmax? the m* ones or the all caps ones?
- What do i need to exactly put into the .dae file joints-array portion? Another thread was stating several solutions, none of which worked and/or made much sense
- I am upgrading to 3dsmax 2014, which exporter plugins will work, and, more importantly, will 3dsmax 2014 work for me at all? Are there any more ugly workarounds that need doing?
-
hmm I will have to think on this some more again, thanks for the answers so far. maybe I was indeed overthinking some of the things here, and I will take another look into the scripting and see if I can't actually work it in the simple ways you have suggested.
thanks again for the help by the way, the pictures especially have helped me quite a bit, along with the examples. My initial idea for reducing the interaction to the XY plane was that i only would be dealing with one value i could throw into various self-made functions, but i do tend to sometimes overthink simple solutions and make a complex construct instead.
-
Well, the above solution seems simple, but it also rotates the ray around the X and Y axes. The issue with that is that I don't want to say, cast a ray uphill into the sky when I travel uphill, neither do I want to llRotLookat() above or below the height I am currently at. That is why I wanted to simplify the entire process into the X/Y plane, so I could model the current facing of my "vehicle" as a simple float, being the world Z rotation.
It has several reasons, one is simplicity, the other is the ability to simply rotate the object by modifying one variable, or being able to say, cast two rays instead of one, one slightly off to the left, one off to the right, to get a better idea of where the obstacle is at and react in a more granular way.
edit:
There is another important factor. Due to me using llRotLookAt(), the vehicle's Z axis is pointing forward, and positive X is pointing down, aka the vehicle is rotated +90° on the Y axis. This would make raycasting based on the object's rotation tricky, because imho they would just be cast into the ground that way? Unless I am seriously getting my math wrong. These last days of trying to figure it out haven't been kind on my brain at times.
-
ah, let me try and break it down a bit more then.
What I'm trying to do is a vehicle which turns via llRotLookAt(current angle + turning angle). and it casts a ray along the angle it is currently facing. however, i want it to be treated as if it were moving on the XY plane exclusively to simplify the movement. aka to not cast a ray upward when it travels uphill for instance.
for this, i need the current angle around the world z axis - so i can use llAxisAngle2Rot(<0, 0, 1> * angle); to do an llCastRay infront of where the object is traveling.
The entire rest of the code is standing and seems to do as it should. The mathematical issues that remain is:
- How can I turn any random x/y/z rotation into JUST the Z axis angle?
- How can I SET this angle reliably? There seem to be a lot of flips going on when reaching certain angles
-
well, the actual llRotLookAt() isn't the problem at all though, I'm afraid.
The problem is turning a 3D rotation into the z-axis rotation angle, and turning this angle back into a rotation, for various functions I use (lookats, raycasting etc).
The math does seem to have considerable issues with the gimbal system, so I'm hoping for input on how to do the math the right way.
-
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.
-
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?
-
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
-
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.
-
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!
-
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.
-
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!
-
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 customizabilityThat aside, its looking great so far, and lightweight
-
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
-
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 anymore
- Less inventory clutter from outdated landmarks
- With 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 grid
- Location 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 :)
-
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
-
sounds good to me, thanks for sharing that insight. thatll prove handy when i make rezables (furniture and whatnot) for mesh
-
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!
-
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.
-
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.
-
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.
-
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.
-
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.
Facebook
Instagram
Twitter
YouTube
Flickr
Using standard SL mesh as fitted mesh base
in Mesh
Posted
I've recently been hard at work on making a materials-based full mesh avatar. For practicality's sake, I wanted to use the standard SL avatar mesh as a base body for my anthro dragon, thinking that way it would be easy to make fit with mesh clothing, and seeing how regular skins don't support materials.
That said, I imported the .FBX file of the female body rig as a test, and trimmed away the unneeded parts without editing the skinning any, then imported it into SL along with the limbs. Essentially, it looks good. joint deformations seem to be spot on with the base SL mesh. However the problem begins when I mess with the sliders. The breasts deformer seems quite a bit offset from where one would expect it, and some other sliders have some weirdly adjusted effects.
Since I used the rig the FBX file (taken from the fitted mesh page on the wiki) came with and the original weighting, I wonder, am I missing anything? Is there a way I can get a better result with this method? Essentially I'm hoping for a bit more accuracy, so maybe someone played with importing the base avatar into SL in the past and can help me out. I'm thankful for any information :D
On another note, if anyone knows anything on how to add custom bones to the skeleton - i know it can be done, ive seen rigged talkjaws on various avatars before - then I would also appreciate it greatly. I'm trying to make a "Chin" based bone in 3dsmax, but have yet to figure out how to correctly set up/export it