Sylvia Wasp
-
Posts
269 -
Joined
-
Last visited
Content Type
Forums
Blogs
Knowledge Base
Posts posted by Sylvia Wasp
-
-
1 hour ago, Da5id Weatherwax said:
I'm really sorry if I came across as unhelpful, but in all honesty my - admittedly a bit glib and brief - answer was why it wasn't working.
Look at it without the texture applied, looking where the edge loops are going, if they are following the contours of the fitted model well...
Now, on this one, in the picture I replied to you can see a couple of serious issues there. The horizontal loops are going up and down like a tarts knickers without any real justification for them to do so in the shape you're trying to achieve in the model. The paths of the vertical lines are so distorted that even without the somewhat funky triangulation it would be hard to trace them. You do expect that there will be some curving around - you want your edge loops to curve across the contours of a body, dipping down to outline an underbust curve or accentuating a cute butt a bit - but when the edge loops so blatantly do not respect the form they are trying to outline you are going to have problems.
If you beat your head against the UV unwrap hard enough you can compensate for this - It's certainly possible that by tweaking the UV map vertex by vertex you will be able to achieve a distortion-free mapping of your texture on this model as it stands but that's going to be a lot harder, take many hours more and be and front-loaded with problems if you don't clean up the topology before you go for an initial unwrap.
Interesting stuff.
I should clarify ... I didn't make this mesh or have access to it in Blender or Marvelous Designer, I'm just trying to texture it and at the same time understand what's wrong with it so that when I am trying to make my own mesh I don't make the same mistakes.
Sylvia
-
2
-
-
21 hours ago, Fluffy Sharkfin said:
Applying a UV grid texture (like the one below) can help you discern if the UV mapping is uniform across the entire mesh or if some areas have been squashed or distorted in some way. That will give you some idea of the extent to which you'll need to distort your textures to fit the UV mapping of the mesh correctly when creating custom textures for it.
...
As for deformations that occur due to the shape you're using try rezzing the mesh rather than wearing it, assuming the creator has uploaded it at the correct scale it should conform to the default shape used to create the mesh.
As for reasons why this particular mesh is doing this, it's probably either because the creator didn't make the UV mapping uniform to begin with, or because they altered the mesh after applying UV mapping and in doing so compressed the UV, thereby causing the texture to become "squashed" on those polygons.
Well, with your UV texture applied, it makes what's going on at the edge obvious, but any grid would do the same.
I was actually hoping to see a more "tangled" result. What I'm trying to get at is what *causes* it, so I guess the answer is ...
"not remapping the UV before upload"?
Sylvia
-
20 hours ago, Peony Swee*****er said:
My guess (on that 18 pixels thing) is that the UV map does something odd as it wraps around the edge of the mesh, probably emphasised by the way it was weighted to the various bones. The odd stretch in the mapping probably wouldn’t normally be noticed until you try with a really precise design like your lace.
I’d also guess that this was made in a program like Marvellous Designer, and that the mesh and the UV maps were auto generated. As Da5id said, a retopo would have probably fixed the mapping problem, since you’d also remap and have a nice straight edge to work on instead of lots of weirdly placed and shaped triangles.
I'm still getting my head around "retopo" but I'm thinking this is something that could easily have been done in Blender *after* importing from Marvelous Designer.
-
18 hours ago, OptimoMaximo said:
The issue is simple: that mesh clay comes from Marvelous Designer and the way it creates a mesh with its UVs is the problem. That mesh started as a rectangular pattern that was then stitched in a tapered shape. The UV though aren't tapered, so the larger side shows a stretch and I'm betting that if you perform the same test on the bottom edge, you will see a squashing effect,quite the opposite of what you've been experiencing with the top side.
Well, I'm hopeful that it isn't as simple as blaming Marvelous Designer. That program is about 1,000% better at making clothes for Second Life than any other and I hope to buy a copy once I have the cash as part of my program to make my own meshes.
My understanding is that even if you use Marvelous Designer that it's essential to import into Blender for many many "adjustments" before importing into Second Life so perhaps the "retopo" (still figuring that out, lol) should have been done there. It seems like the issues with this mesh *could* certainly have been fixed at that stage.
Sylvia
-
23 minutes ago, Da5id Weatherwax said:
That thing needs some serious retopo anyway
not helpful.
I already suspect it's a crappy mesh as I said. I want to learn exactly *why* it's a crappy mesh and what actions in creating it, led to the problems it has.
-
9 hours ago, Chic Aeon said:
The little balls are on the mesh. The mesh will stretch to conform to the SHAPE of the avatar. If the shape of the avatar is NOT the same shape as the reference model used in making the garment the textures will stretch. You see this ALL the time (even on us skinny gals) so not unusual. If you test on someone that is really hippy you will likely see more stretching. This has been around long before mesh clothing came into being.
Ah, thanks. Of course. I feel stupid now. 😕
Although, why it's stretching right at the edge of the garment and not stretching a half an inch further in still bewilders me a bit. And I tested it on my own skinny self too, so presumably it will stretch even more on curvier girls.
...
EDIT:
OK, I know it's gauche to reply to your own thread but ... new information!
Because I couldn't figure out why the image was only distorted at the mesh edges ... I moved it down (away from the edge) and the problem fixed itself (see attached image). 😮
So after a bit of screwing around I figured out that for some reason 18 pixels from the edge (not 14, not 16) the image is no longer distorted. Luckily for me I'm making something with alpha edges anyway, but seriously ... I'd like an explanation. This trick wouldn't work on a regular garment using this mesh.
- Does anyone know why this mesh does this?
- Is it just a poorly designed mesh?
- Is there some (shoddy) technique that results in this kind of thing?
I have never seen this before.
Sylvia
-
2
-
-
I've been making clothes (texturing mesh objects) in SL for a while now and came across something I don't understand. Maybe someone has seen it before and can at least explain it? (I'd like to fix it, but it seems like it might just be a property of the mesh itself.)
I purchased a full perm mesh object and I'm trying to texture it with a decorative edge.
WARNING: The pictures here are just rough tests so obviously it's not finished work. However, the problem can still be seen.
The first shot shows the texture in Affinity Designer, and yes, there is clippling (it's a rough test!), but mostly the little balls along the bottom border are generally the same size, right?
The second shot shows me wearing the test product in-world, and clearly ... the little balls along the border vary from 100% - 200%. The ones closer to the edge of the mesh are all squashed and shrunken, whilst the ones further from the edge are almost twice the diameter.
Anyone know what (the F) is going on there?
-
On 2/21/2020 at 3:12 PM, Keira Linden said:
Dismantled
Huntsman
Littlepaws
Nova
Ravenhurst
Wumpkins
YeetlyWow. I guess the "winners" were chosen by a random algorithm? lol.
how completely uninspiring these are.
-
1
-
-
On 2/26/2020 at 5:31 PM, Gadget Portal said:
Because you are being unreasonable.
Nailed it.
Nah.
Everything I'm asking for is not only reasonable it's standard, and provided by every other mesh body brand.
I'm not looking to "promote my brand" (I don't have a brand and don't personally believe in brand politics/promotion, lol), I'm just looking to let users know about new products I've created for them.
Not only is there a HUGE difference between a "notice" and a "promotion," the groups in question specifically address this through the use of rules.
There are rules on the type of notice, the frequency of notices etc. and the *only* people who can post notices are those who have specifically requested access for that purpose and have been screened by the group owners (the actual people who are "promoting their brand").
Possibly because neither of you are creators and don't post to these sort of groups, you don't know this?
Geez, I feel like I'm arguing about these groups exclusively with people who are completely unfamiliar with how they work. 😀
In regards to my question that started this, it seems that the answer is probably ... "no"?
I won't be checking back after this kind of response, so ... argue amongst yourselves, lol.
Sylvia Wasp
-
On 2/24/2020 at 10:42 PM, janetosilio said:
So because there's no Belleza group that allows you to spam ads....they must not want you to create for them? Because....they're....different....
Got it....
You missed the point of there being other avenues to advertise besides sending group notices though.
Wow, this is such a HUGE misrepresentation of what I said.
There is no "SPAM." These are notification groups (with rules!) that exist specifically for the promotion of the mesh body brand in question and also to allow makers of clothing or accessories for those brands to let users know of new products.
All I'm saying is that I want a (very normal, typical) route for notifying Belleza users of new products that I am making explicitly for them. And that every other mesh body has such a group/route/method.
-
On 2/24/2020 at 3:41 PM, Theresa Tennyson said:
Isn't it your brand you want them to promote?
No, lol. I don't have a brand and I don't believe in brands per se either.
-
3 hours ago, janetosilio said:
It’s the second most worn body.
Honestly, I don’t even pay attention to group notices. I treat them like spam, close the box immediately when they pop up. I’ve been doing that for years.
The best way to advertise now is through social media. Apparently, they are cracking down on Flickr, but that’s usually where I find out who has things I might be interested in. You can post ads, but not links.
Well, I would disagree on "second most worn body" it depends on how the pollster makes the poll. 🙂
The numbers also show that Belleza Freya is pretty much the only one of the three Belleza's that's still popular with designers (because sales).
Anyway, Belleza users seem to be different from Tonic/Maitreya/SLink users and probably always will be.
I WANT to make clothing for Belleza Freya, and I AM making clothing for Belleza Freya, I'm just saying that they are making it much harder than it should be to make Belleza users aware of that fact.
They just don't seem to have even basic infrastructure for promoting their brand.
Sylvia
-
3 hours ago, Syn Anatine said:
Are these groups owned by the Belleza creator? If no, then....why take it out on the brand? That doesn't make a lick of sense.
I'm not "taking it out" on anyone. You're just trying to make me sound angry or unreasonable.
I'm just saying that every body type has groups precisely for this sort of thing, that Belleza seems to have one too, but ... that there seems to be basically "no one home" when I ask about advertising etc.
-
I know the title is a bit cheeky, but seriously ...
I have a small store where I make clothing for (female) avatars and I recently decided to expand the body types I support. I *had* been only supporting Tonic (the best mesh body) and Maitreya (the most popular mesh body), but I decided to expand my repertoire to include SLink, and because it's still very popular (apparently) .... Belleza Freya.
I then went about joining all the groups and trying to find out which ones I could use to announce products in. I found out how to do it with SLink right away (they have rules for it, like everything, lol) but it seems that Belleza is completely lacking.
There are lots of Belleza groups, but only three with large followings that seem like the places to announce new product. I tried asking in the groups, I tried finding out the owners of the groups and IM'ing them, and eventually I even dropped notecards explaining myself to the owners of these groups. Two of them even say in the group description that you can "apply" for permission to post notices in the group if you are a creator and I've done that.
What I've got back ... (and this is weeks ago!), is sweet F-all. Nothing. Nada. No contact.
I spent many days updating everything I make to support Belleza Freya and now I'm thinking I probably shouldn't have bothered.
Sylvia.
-
1 hour ago, Wulfie Reanimator said:
"Micro" mesh is just regular mesh with a trick. For example, look at my beautiful jewelry part:
Marvelous, I know. The problem is that this part can only be sized down to 0.01 because of SL limits. That's too big! But what if I put a box around my work that's twice the size?
It can still be sized down to 0.01, but now the detail I want people to actually see is 0.005 in scale!
So what happens when I try to scale this up? Well, SL has a maximum scale of 64. That means people can only see the inside at a size of 32 meters.
Cool explanation as always. 🙂
Pictures really help too.
Sylvia
-
1 hour ago, Pamela Galli said:
The bounding box should have a limit of 64m. Unless I am wrong.
Cool. 🙂 I don't actually need it as "big as a house" but I was worried that they were somehow un-resizeable beyond the micro-realm as it were.
Sylvia
-
1 minute ago, Chic Aeon said:
Keep in mind that if you buy "micromesh" parts EACH PART will count as half a land impact, making your items VERY "primmy". Most jewelry is made as a single mesh item WITHIN 3D software. So your base plan may be faulty :D. Just a warning.
Personally I wouldn't buy anything from a seller with such a nasty message.
Thanks for the heads up, but I thought that worn items don't count as much as rezzed prims, no?
I mean back in the day, everyone was walking around with jewellery made out of hundreds and hundreds of individual prims (ie - hundreds of LI if rezzed on the ground).
Sylvia
-
I'm considering getting into making jewellery and I need to buy some FP micro mesh for that purpose. The seller in question has a (rude IMO) 'no questions, no support, no refunds, no returns' kind of policy so I can't ask him the question before the purchase.
The (stupid) question is ... I know "micro-mesh" is designed to be small, but how big can it actually get?
Like, can I buy a "micro-mesh" item and then just drag the handles out until it's as big as a house? What would happen? What's the essential difference between "micro-mesh" and regular mesh anyway?
Okay so I guess that's two questions lol.
Sylvia 🙂
-
19 hours ago, Mollymews said:
lets look at this from a different pov. A pov of mathematics that can lead us into a situation that we have no reason to be in
we have a script which listens on a channel, where the possible number of channels is 2 ^ 32 - 1 (not counting the debug channel) = 4,294,967,295
the script listens to a named object. A name which can be length 1 to 63 where there are 94 possible ASCII-7 chars to choose from
length 1 = 94 ^ 1
length 2 = 94 ^ 2
length 3 = 94 ^ 3
...
length 62 = 94 ^ 62
length 63 = 94 ^ 63add them all up: 2.0497E+124
multiply this by the channels: 2.0497E+124 * 4.29E+09
the result is: 8.80E+133. A number that is 134 decimal numerals long. Which is a really big number
and because it is we think that the mathematical probability of our script colliding with another script is so tiny that we are not going to worry about it
not worrying about it, is like betting that we are not going to win the Lotto. A thing about large numbers, is that somebody does eventually win the Lotto. We are gambling that it will never be us
what we should be thinking is that our script is not a lottery ticket. Is a script to change the textures on our object/garment
thanks Molly 🙂
-
1
-
-
On 2/2/2020 at 11:35 AM, Mollymews said:
adding to the conversation
it isn't greifers so much we worry about, is all the other people who make appliers
the goal is to make our code as efficient as possible. Leaving communications holes in our code, makes our code inefficient
looking at the communications model for your (Sylvia) objects and HUDs so far
key2chan - gives each of our customers the widest possible opportunity to be on a separate channel
listen for named HUD - as we can uniquely name our products, then no two different products of ours will ever cross talk
llRegionSayTo(llGetOwner().... - our HUD will never send a message to a script owned by another person
adding to this
check for Owner - excludes any message from a scripted object with the same name as our HUD, on the same Key2Chan channel, owned by someone else
check for Creator - excludes any message from a scripted object with the same name as our HUD, on the same Key2Chan channel, made by some one else, owned by the owner (our customer)
adding these last two checks means that our communications model is 100% efficient
Okay so I added the code because better safe than sorry 🙂 (thanks for the code BTW, awesome, simple and very clear as usual)... but you've only (slightly) convinced me of the necessity of the first check (for owner), and not really convinced me of the need for the second check (for creator) at all.
Your problem with the ears seems to stem from two things that will never happen with my products, which are:
- multiple HUDS by different creators for the same product. The only way I could see this happening is with Gacha (and I am opposed to Gacha on moral grounds, lol)
- HUDs that are not uniquely named. (I would just never, ever do this)
It also still seems to me that because I'm using this in the HUDs ...
llRegionSayTo(llGetOwner(),cmdChannel, (string)index);... that a HUD can only talk to the owner of the HUD, so if the HUD is owned by someone else, it can't communicate with anyone else. So it still seems to me that we're talking about griefers. Someone who's essentially made a hacked (illegal) version of my HUD that can talk to other owners.
The second situation also seems to necessitate someone making a hacked (illegal) version of the HUD and the product, and that someone who normally buys my products has unwittingly instead purchased this shady product (or more likely "found" it in a sandbox).
Both, extreme edge cases IMO, both requiring illegality, and in both cases the intention of the griefer would be to do a lot more damage than just ripping off my few silly products. More likely there would be some other nefarious code payload that would be the focus.
Anyway ... adding them anyway!, (and thanks again), but I think we're really dealing with secret agent levels of security here.
So here is the final, final listen code I got (for anyone following and wanting to reproduce the thing):
listen(integer channel, string name, key id, string message) { list crown = llGetObjectDetails(id, [OBJECT_CREATOR, OBJECT_OWNER]); if ((llList2Key(crown, 0) != llGetCreator()) && (llList2Key(crown, 1) != llGetOwner())) return; integer index = (integer) message; string texture_key = llList2String(textures, index); llSetLinkPrimitiveParamsFast(2, [ PRIM_TEXTURE, ALL_SIDES, texture_key, <1.0, 1.0, 1.0>,ZERO_VECTOR, 0.0, PRIM_NORMAL, ALL_SIDES, texture_NRM, <2.0, 2.0, 2.0>,ZERO_VECTOR, 0.0, PRIM_SPECULAR, ALL_SIDES, texture_SPC, <1.0, 1.0, 1.0>,ZERO_VECTOR, 0.0,<1.0, 1.0, 1.0>, 51,0, ]); }I switched creator and owner around so it makes more sense with the variable name.
thanks for all the help everyone!
Sylvia
-
17 hours ago, Wulfie Reanimator said:
I forgot you're already using RegionSayTo, so the "duplicate channel" issue isn't really a problem after all.
The effort it takes to totally prevent any kind of exploit is literally one line of code that I already included in this thread. If you think it's not worth it, that's your choice. A choice I can't understand, but it's not my product so whatever.
Well, I might add it anyway since you're being so "passively aggressive" about it, lol.
But it's literally adding yet another nesting if-else statement (the very thing I started out to avoid) just to absolutely rule out the minuscule chance that some griefer (who has read this thread BTW) hates me so much they are going to actively try to subvert my code, in order to play havoc with the textures on the 8 or 10 people who actually buy my clothes.
I mean, I'm a small business and I operate at a loss. I only make the clothes so as to provide inexpensive, yet quality options for Tonic body users.
It's more of an Anti-Capitalist action than a business, lol.
Sylvia,
-
49 minutes ago, Wulfie Reanimator said:
Not quite.
I assume the HUD name is always the same, regardless of owner? Meaning if I had the HUD, it would be called "Some HUD" and if someone else had the same HUD, it would also be called "Some HUD". If your listener is acting on all messages heard from an object called "Some HUD", it's easy for me to break all of your products.
A channel generated directly from the owner's key is not unique nor secure.
"0x"+(string)ID creates a hexadecimal number with 4 bytes (8 characters, like 0x12345678).
default { state_entry() { string avatar = llGetOwner(); llOwnerSay(avatar); // output: "779e1d56-5500-4e22-940a-cd7b5adddbe0" string hexadecimal = "0x" + avatar; llOwnerSay(hexadecimal); // output: "0x779e1d56-5500-4e22-940a-cd7b5adddbe0" integer number = (integer)hexadecimal; llOwnerSay((string)number); // output: "2006850902" (= 0x779E1D56) } }
Note that the first part of a UUID is 8 characters long. It's the same number.
The first problem is that there may exist other avatars who have a key that is identical no matter which 8 characters you pick. You can't pick more characters because they'll be ignored when typecast to an integer.
Besides that, if I create a new object and rename it to "Some HUD", I can just put my own script in there so it starts sending random messages on channels based on the avatars around me. Even if I don't know which part of the key you're using, the options are pretty limited and I can just send messages within ~200 channel range of different parts of the key.
For these reasons, you absolutely should add an additional check to make sure that "Some HUD" is owned by the same owner.
Hmmm ...
It seems like a very very very very very unlikely situation that you're talking about IMO.
I mean I'm going to get a completely unique number almost every time despite the outside chance that two avatars *may* generate the same number.
Also, we're already talking about active griefing rather than just covering off stupid mistakes, two avatars in the same room with the same product, or sloppy work on my part. Someone would have to do a lot of work to construct something just to screw around with another avatars clothing texture HUD, and why would they?
Sylvia
-
1 hour ago, Wulfie Reanimator said:
This does not limit the listener to objects owned by the owner. In that line of code you've created a listener that will never hear anything, because it's listening for a specific object name and a specific avatar key. By definition that's impossible to satisfy, you have to leave out the llGetOwner part and check for llGetOwnerKey separately. See:
default { state_entry() { llListen(0, "Object", llGetOwner(), ""); } listen(integer channel, string name, key id, string message) { llOwnerSay("Heard!"); // Will never happen. } }
Yes, I discovered this in testing today.
The whole thing stopped working and since the only thing that was changed is the NULL_KEY, I went back to the old version and it worked again.
I think I'm just going to leave it the way it is (was) because I think having this at the top of the HUD code ...
string HUD_Name = "some HUD"; integer cmdChannel; ... integer Key2Chan(key ID) { return 0x80000000 | (integer)("0x"+(string)ID); }and this in the Mesh code ...
string HUD_Name = "some HUD"; integer cmdChannel; integer Key2Chan(key ID) { return 0x80000000 | (integer)("0x"+(string)ID); } ... default { state_entry () { cmdChannel = Key2Chan(llGetOwner()); llListen(cmdChannel, HUD_Name, NULL_KEY, ""); ... }... does essentially the same thing.
I'm already communicating between a named object on a secure channel that's specific to the user/owner of both objects. The HUD even names itself on startup so it can never be called anything else. The mesh can't listen for any other HUDs other than the named HUD, and the user would have to own both objects anyway. No other users should even be able to listen in on the same channel.
I think that covers everything except ... "I've stupidly rezzed multiple copies of my own HUD all over my property and am just randomly clicking them now." Even in that case, the result would either be the very thing the user wanted, or it just wouldn't work at all AFAICS.
Sylvia
-
6 hours ago, Mollymews said:
i just pick up a little thing in the object script there is a listener
llListen(cmdChannel, HUD_Name, NULL_KEY, "");narrow the listener down to the named HUD on the channel owned by the Owner
llListen(cmdChannel, HUD_Name, llGetOwner(), "");
this will prevent the object being changed by a device owned by somebody else which just happens to have the same name and is operating on the same channel
Done
Quoteanother little thing in the HUD script
because we have a button named '0' then we have a issue. Any string that does not start with a number when cast to an integer will be 0 there are number of ways to resolve this. A simple way is name the buttons from 1 to 9, instead of 0 to 8, then deduct 1 and test for it
touch_start(...) { integer button = (integer)llGetLinkName(llDetectedLinkNumber(0)) - 1; // any prim name that is not a number >= 1 will result in button being -1 if (~button) // >= 0 { ... code here same as ... if (button >= 6) ... llRegionSayTo .... } }
and Done. Both excellent ideas.
One last thing that always secretly bothered me though ... I don't "handle" the listen in the mesh object.
Is it really necessary for a simple thing like this? Should I be using a timer and deleting the listen after a set time? It seems like extra complication and also something that will get in the way of utility of the product itself. If the HUD stops working after x seconds or whatever, the user will be left thinking it's broken. Won't the listen just disappear by itself?
Sylvia
Facebook
Instagram
Twitter
YouTube
Flickr
mesh texturing problem
in Building and Texturing Forum
Posted · Edited by Sylvia Wasp
This is the kind of fiddly nonsense I'm trying to avoid, lol.
I keep hearing about "Local Textures" but I can't see the option in Firestorm, so yeah ... everything I make costs thousands in uploads. 😡
This "retopo" thingie seems like a gross misuse of the real meaning of the word "topology" 🙂 but that's neither here nor there.
I understand that the sort of "post processing" (retopo) necessary in Blender *after* using Marvelous Designer" simply wasn't done here. Which is great for me because I'm a very detail and process oriented person who hates sloppiness so I don't imagine I will be making these mistakes when I make my own mesh.
I will check out 3D Coat for sure, but I'm betting it's Windows only? (because I haven't heard of it). Painting right on the model has always interested me although for most projects it's not necessary.
I like to use vector based tools more than bitmap ones though, especially given the extremely low res textures we have to deal with in SL. Here it is 2020 and most of the time our clothing is still only using 500 pixels or so of detail. Another reason why making your own mesh and your own UV mapping is the only way to go really.
thanks for the advice, 🙂
Sylvia