Kwakkelde Kwak

And another real "duh" moment I have a lot of those lately. Thanks for the tip! The hands aren't really an issue, I could add a button for hand poses in addition to the sliders for body, torso and legs.

I'm sure the community would love to see you expand your explorations. Anyway, be glad you don't have to write an avastar What I want for 3ds Max for personal use is a fraction of it and it's pretty mindbending if you ask me. Then again , if you want to label people, I'm a builder, not a scripter. That really does not help.

Dillon Levenque wrote: Kwakkelde Kwak wrote: For the right price I'm up to anything, this evening or what's left of it. I'll swing from left to right and might even twist. Uh huh. Meet up with Maddy and there's a good chance you might do just that. In the wind. Exercise caution. I'm not much of an outdoors person, I might pass this time.

Madelaine McMasters wrote: Kwakkelde Kwak wrote: Madelaine McMasters wrote: Are there any left? I think most are right. I know they often escort those on the right, but can we be sure that's also their persuasion? Might they be from the left, and nefarious? You doing anything this evening? ;-) For the right price I'm up to anything, this evening or what's left of it. I'll swing from left to right and might even twist.

Madelaine McMasters wrote: Are there any left? I think most are right.

I can't show you the entire workflow/process, that would take too much time. What you can do it search for "3ds max viewport canvas". Viewport canvas is the 3ds max 3d paint tool. 's a video.

To clarify the idea: In the above picture you have a single plane with two materials. The corners are 1/8 of the total for easy texture repeats and offsets. You can map the dark gray area as a plane, using the full canvas. It has no normal map at all. The corners you can map as a plane too, again using the full canvas. With the diffuse texture repeat at 0.125 and the right offsets for each corner they can use the exact same diffuse texture as the big plane, leaving no seams. You can assign a normal map with a 1x1 repeat to them. Alternatively you could map the entire thing as a plane and play with the repeats (8x8) changed for the normal maps of the corners. Come to think of it, that's probably easier. Drongle McMahon wrote: "On curved surfaces this won't work without vertex normal matching." I don't follow the quoted bit though. Aren't vertex normals preserved across material boundaries? I'll have to try it. You are 100% right about the vertex normals, no idea where my mind wandered off to when I wrote what I wrote. The lacking ability to edit the vertex normals is only an issue when you push two curved elements (as they are called in max) or objects together.

leliel Mirihi wrote: Also while the detail may be non-uniform on the mesh it doesn't have to be on the UV map. While this is very true, it's not as straight forward as it sounds. In most cases you don't set your UV map up for your normal map, but for your diffuse map, which in most cases will be more or less uniform to the mesh and in cases like the bolts or tapered box completely non-uniform to the geometrical detail. You could split your UV map so you end up with multiple materials/SL faces, which would overcome this particular issue but raise some new ones instead, especially since (to my best knowledge) Blender (still) doesn't support vertex normal editing. On flat surfaces like Drongle's or mine, it could/would work. Isolate a small square around the bolt and give that a normal map. With the right offset/repeat it could share the diffuse map with the rest of the object. That doesn't cost you a whole lot of vertices. On curved surfaces this won't work without vertex normal matching. Texture memory is an artificial construct of the viewer that is completely disconnected with reality. On the hardware side dedicated texture memory fell out of favor almost 15 years ago. The reason why the viewer can't use all the vram modern cards have is because it still clings to this out dated concept. LL knows this system is broken and needs to be removed but they're lazy so we should light a fire under them by abusing it as much as possible.**Only uploaded images may be used in postings**://secondlife.i.lithium.com/html/assets/emoticons/mattemotes/evil_invert.png" border="0" alt=":matte-motes-evil-invert:" title="" /> It being an outmoded (is that the right word?) concept doesn't change the fact it is reality. It's something we will have to live with and take in account when we build things. Agreed Agreed

Cathy Foil wrote: What LL did was in Maya took the default avatar shape "Ruth" and duplicated it creating a second avatar mesh. This has always puzzled me. The default avatar we get to work with is not the same as Ruth (assuming Ruth is the avatar we get from the Ruth folder in the library or the one we get after a "test female", which in turn aren't the same either). For example, Ruth (library) has Torso muscles set to 43, where the avatar we can download has torso muscles of 50. Butt Size, Belly Size, Breast Cleavage/Buoyancy/Size, Foot Size and most, if not all, of the head sliders are not the same either. The body sliders aren't that hard to figure out, although Breast Cleavage seems to be between two integer values in the default avatar (19.something) by the looks of it. The differences between the default and "Test Female" avatar are even bigger, although the head is an almost match.

leliel Mirihi wrote: Kwakkelde Kwak wrote: Of course when you compare a high poly model to a low poly model with normal maps, the low poly will be better memory wise. Normal maps are textures though and Second Life has a very limited amount of texture memory. In other words, if you have a lot of VRAM, SL will run out of memory before your graphics card does. Vertex date takes memory too. Develop -> Show Info -> Show Render Info to see how much. I'm shure everyone has heard about the GDC presentation approaching zero driver overhead by now. It's worth pointing out that many of their examples were bandwidth limited by the PCIe bus transfering vertex data. I don't think one percent of one percent of one percent of the users has ever heard of "GDC presentation approaching zero driver overhead". Anyway, I am talking about the maximum of 512 MB reserved for textures. No matter how muh memory a vertex uses, it doesn't qualify or is used as texture memory. If it is, the term is chosen poorly at best. Obviously there's always exceptions to everything, that goes without saying. Tho I don't think a shape as simple as a pyramid is a good example of that. I think you have false expectations of the SL community then. Most builders don't have a clue about 3d modeling. If they are told normal maps are good and polygons are bad, they might use a normal map for just about anything. So a single rivet on a big plane, or in this case, simply because that was faster to model, a single tapered box in a big plane. Going by what I've seen over the years, they'll probably use a normal map on top of a high poly model, making it not too detailed, but superextramega detailed. No. Normal map != normal gbuffer. The viewer will use 4 bytes for normals and spec exp even if you don't have a normal or spec map because the normal gbuffer is for the whole screen. The same as how the "framebuffer" (diffuse/albedo gbuffer) always has an alpha channel even if there isn't a single alpha texture visible. I thought read somewhere (it's far far away in the back of my mind) that it's best to use the alpha channel of your normal maps for something because it's used anyway. Maybe the person writing it was mistaken, maybe I misread. I don't know. Anyway, the entire point is: sometimes it's better to use geometry, sometimes it's better to use normal maps. It's always good to use as little as possible.

leliel Mirihi wrote: Kwakkelde Kwak wrote: Jenni Darkwatch wrote: IIRC normalmaps are merely a shader operation on a GPU. As far as calculations go, but they do use more VRAM than geometry of course. Then again, with a good normal map you can probably get away with a smaller diffuse map. Vertices use significantly more memory than normal maps. Vertices use 40 bytes for position, normal and color, plus 8 bytes for texcoord and however many for weights for skinning (note color and texcoords use floats). Normal maps are just 3 bytes per pixel. A 512x512 normal map has 262k pixels but takes up the same space as 19.6k vertices @ 40B each. Altho be warned there isn't a 1:1 ratio of nomal map pixels to pixels on your screen, there's a whole lot of filtering and interpolating going on before you see the final result. Of course when you compare a high poly model to a low poly model with normal maps, the low poly will be better memory wise. Normal maps are textures though and Second Life has a very limited amount of texture memory. In other words, if you have a lot of VRAM, SL will run out of memory before your graphics card does. Then there's this: The left object is rather heavy, with 4410 tris and 8820 verts (if it was uploaded to SL). The right object 18 and 28. Baked onto a normal map, there wouldn't be any difference though (apart from the fact you can of course tile the map of the left object, but this is an example). I'm pretty sure using a normal map for the object on the right, rather than geometry, wouldn't do you any good memory wise. btw, doesn't a normal map always use the fourth channel's memory, even if it's not used, taking up 4 bytes per pixel?

hopefully... but also presumably:) ehh I hope.

Jenni Darkwatch wrote: IIRC normalmaps are merely a shader operation on a GPU. As far as calculations go, but they do use more VRAM than geometry of course. Then again, with a good normal map you can probably get away with a smaller diffuse map.

Aquila Kytori wrote: So my question is, if the Physics shape isn't actually rotating why bother with Cylinders when cubes will do? I haven't tested with square wheels, but I suspect you can run into some problems when the surface you "drive" on isn't smooth. The vertical front of a box can bump into small things rather than deflect. btw The reason why the physics shape isn't rotating is because the wheels move with a local (local as in on your computer rather than the server) rotation. With an actual rotation they wouldn't work.

Gaia Clary wrote: btw: Our addon reads these files and i am almost sure, LL knows how to create and read these files as well :matte-motes-sunglasses-3: That is what I thought (about avastar) and the avatar using morphs rather than volume bones, explains why LL didn't release an avatar with such a setup. I was just a little slow realising that. So instead of getting the weights as close as possible on the avatar, I'd better rig the avatar to the standard skeleton and use the morph targets. After reading up a bit today, I understand I am about 5 years late:) Thanks for pointing me in the right direction with the files.

That clear up a LOT! Thanks

Cerise Sorbet wrote: Oh, yeah, the collision volumes aren't really a weighting story, they're just bones and the avatar body doesn't use them directly. But fitted mesh does, so... Are you saying breast size and butt size for example are skin morphs and the extra bones are moving with the sliders so you can sort of follow the morph with a mesh shape controlled by the bones?

And again, as far as I can find, no collision bones there...

That looks like it's about morphs at first glance. I don't see anything mentioned about weights. Something makes our avatar skin move, probably a local file. So the weights have to be hidden in there. How hard can it be to extract them? Or....are the weights in the .llm files and did LL lose the ability to open them without a viewer? That would be something. EDIT..just found an old thread (in which you posted too). Someone converted the .llm files to readable txt files. Yes there are weights in there, but as far as I can see only the mBones are in the file, no collision bones. So I would say...there's another file.

Ah, SL relics That's final then, no need to fiddle with them, not that I was going to anyway. One "why on earth" question remains though. Why didn't/doesn't LL release a dea/fbx (or blend/ma/mb/max) file with their weights, so the community doesn't have to reverse engineer them?

ok:) then one has to wonder why on earth LL made those two bones.

Since the butt can take the full weight from the mPelvis (the HANDLEs didn't seem to have a whole lot of impact), I wouldn't expect any big problems there. It's just that I thought I read about some issues here on the forum. The breasts are another story, since you can't move the weights from the chest to the PECs. I haven't had any time to have a serious look yet, so far I just built a new rig with all the collision bones appearing as they do in SL. The weights I just copied from the DAE or FBX file from the wiki. That seems to have more issues in the chest than the butt area. All in all it's not bad as a base though. I hope I can free some more time soon. Regarding the HANDLEs. what Cathy said could be easily verified. It would be very possible that they are mostly used for the physics, not so much (if at all) for the avatar shape.

Ok, you just sound a bit like my father, who always bought cars without test driving

Trinity Yazimoto wrote: [...] i have already maya 3d on my comp. I havent tried it yet. Even if i learn fast and have a great ability to learn, my brain has some limits like for everyone else. Im not going to learn software after software without knowing a bit more about the firsts im still learning. So you buy $3500 worth of software, don't care to open it and don't care to learn it?

yw!