Gael Streeter
-
Posts
86 -
Joined
-
Last visited
Content Type
Forums
Blogs
Knowledge Base
Posts posted by Gael Streeter
-
-
Hi,
I am facing a very weird bug I never saw before...
I am working on a lace face mask. I use GLOSSINESS on my lace : https://gyazo.com/f69fc5eeb0319d39afd8ab392e07d1ce
I use the ALPHA channel of the NORMAL map (as stated in the WIKI : http://wiki.secondlife.com/wiki/Material_Data) to adjust the GLOSSINESS level.
But I do not have the same result when I use my NORMAL Map in Local or after I imported it in SL !
Do you have an idea or the reason of this problem ?GOOD RESULT with the NORMAL map in Local : https://gyazo.com/7bc209f29c3c8e63b6a043dceb468882
BAD RESULT once the NORMAL map is imported in SL : https://gyazo.com/5d7211a002306d328b07eb6b3f2b849e
It seems the texture is damaged by the import into SL.
But if I save back this damaged texture on my disk from SL, fix it on my disk and import it again, it is damaged again... grrrrrrrrrrrrrrrr
It drives me nuts! -
On 8/28/2019 at 12:07 PM, Gael Streeter said:
Thank you Vir for the answer.
So this means an Universal should NOT BE USED FOR SKINS (or other plain textures) or it will overwrite all the worn Tattoos (and Skin) below..."for example, with upper body you would have skin, then tattoos, then universals, then shirts, then jackets."
This order is very important to know (for creators and customers), I think. Is it possible to have it fully write down in the knowledge base ?On 8/29/2019 at 11:09 AM, Gael Streeter said:Perhaps, a better solution would be to display the Universal between the Skin and the Tattoos. No ? So the Universal could be used both as Skin and Tattoos. Of course in this case the wearing order between the Universals is crucial...
I come back on the subject...
Indeed, if the Universal would be displayed between the Skin and the Tattoos, it would allow to have HEAD SKINS separated from BODY SKINS.
For me this is an important feature to have!
Quite all the skinners today offer the head skins separated from the body skins. Customers can mix them as they want and for example change the skin of their head without changing the skin of their body.
With the Skin item this is not possible. But it would be possible with the Universal !If skinners are reading, what do you think about this current limitation ?
-
On 8/27/2019 at 11:15 PM, Vir Linden said:
That is normal. Between the various wearable types, there is a standard order - for example, with upper body you would have skin, then tattoos, then universals, then shirts, then jackets. The ordering tool lets you change the ordering of wearables of the same type - say, put one universal over another - but does not let you override the ordering of wearables of different types - say, to put universals above jackets or below tattoos.
Perhaps, a better solution would be to display the Universal between the Skin and the Tattoos. No ? So the Universal could be used both as Skin and Tattoos. Of course in this case the wearing order between the Universals is crucial...
-
12 hours ago, Vir Linden said:
That is normal. Between the various wearable types, there is a standard order - for example, with upper body you would have skin, then tattoos, then universals, then shirts, then jackets. The ordering tool lets you change the ordering of wearables of the same type - say, put one universal over another - but does not let you override the ordering of wearables of different types - say, to put universals above jackets or below tattoos.
Thank you Vir for the answer.
So this means an Universal should NOT BE USED FOR SKINS (or other plain textures) or it will overwrite all the worn Tattoos (and Skin) below..."for example, with upper body you would have skin, then tattoos, then universals, then shirts, then jackets."
This order is very important to know (for creators and customers), I think. Is it possible to have it fully write down in the knowledge base ? -
I just made some tests with the new Universal, notably on the HEAD TATTOO slot and it seems the UNIVERSAL is always ABOVE the other SKIN or TATTOO clothes without taking into account the wearing order.
Is it normal ? Why is it so ? Is it a bug ? -
What is the purpose of the new AUX channels ?
I am afraid that each creator would do his/her own use of these channels and bring to incompatibilities between products.
Do I miss something ? -
8 hours ago, CoffeeDujour said:
You will need a updated body that sets the baked flag, then all your legacy linden clothing can be worn and be applied to one layer of that body.
No, mesh bodies and mesh heads do not need to be updated to allow the Bakes on Mesh on them.
As Bakes on Mesh is in fact "only" special textures, just an applier applying these textures on your mesh body or mesh head (on the skin layer) will show the Bakes on Mesh on them.
Once these Bakes on Mesh applied, they display in real time the system skin, clothes, tattoos... you are wearing.
-
1
-
-
The results are unfortunately the same with the llScaleByFactor ...
I am wondering if this is not a new display problem of SL because I just also noticed some weird display problems on one of my existing HUD (with tiny buttons) I never saw before : the buttons and the background texture do no appear exactly at the right place when I minimize and then maximize the HUD (buttons are moved and resized by script) :
And the display is also refreshed when I change the focus to another window or when I right click my avatar :
(I tested on my laptop also and have the same results with this HUD.)
-
I tried from a laptop and the results are exactly the same as the previous ones...
I will try the llScaleByFactor and let you know...
-
I made a test looking at my main account with an alt account (on the same computer, on two screens) :
- The alt does not see the same as my main account.
- The alt has also a display problem but not exactly the same as the main account.
- Both can refresh their own display by right clicking the object. -
Thank you for your answer Rolig.
I made a loooooot of tests to try to workaround the problem : Change the color, the transparency, the texture, the hover text, the position, the rotation...
I also tested with the official SL viewer.
Unfortunately nothing work!
The refresh is only made when I right click the object or if my avatar moves or if I give the focus to another program!If I get the size of the object by script after the resize, it gives me the right size (and not the displayed one).
I suspect perhaps a rounding error of display...
I have 3 sizes :
vector MIN_SIZE = <0.01, 0.01, 0.01>;
vector RESET_SIZE = <0.04, 0.04, 0.04>;
vector MAX_SIZE = <0.075,0.075,0.075>;
If I go from MIN_SIZE to RESET_SIZE the object (a white eye ball) appears smaller than the real size:
If I go from MAX_SIZE to RESET_SIZE the object (a white ball) appears bigger than the real size:
Real size displayed after right clicked :
Does someone know more about this ?
-
Hi all,
I repetitively change the size of an attached prim by script using the llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_SIZE, mysize]); function and I have a problem of refreshing : the prim is not always displayed at the right current size and I need to right click on the prim to have it refreshed and displayed correctly.
Do you know this issue yet or is it a new one (I am using Firestorm 5.0.11 (53634).) ?
Is there a workaround I can use to oblige the viewer to refresh ?
Thank you in advance
-
Hi Whirly,
this is not directly related to Bento.
Even before if the ears of the Mesh heads were attached to the head with no possibilty to hide them you had problems to put other ears...
With all the different ears available on the market, I think most of the head creators are already aware of that (or they will be rapidly facing all the customers requests).
For example, we, at GA.EG, offer from the start ears separated from our Mesh Heads and Bento Mesh Heads, in rigged and not rigged versions so our customers can do all what they want... -
Ah ! Thank you Gaia for the link and info !
-
Hello,
I am surprised to not see any update of Avastar 2.0.23.
What about the Fitted meshes problem I raised previously ?Does someone have any news about Avastar and when it will become final ?
TX !
-
Ok, perfect I am happy to see that this problem was identified already and fixed in the next release.
I know that Avastar is still in development, that is why I raise the problem I can see...
-
I made some addiotional tests and here are what I noticed : some fitted bones (like NECK or CHEST) seem to be different between Avastar 1.5.9 and Avastar 2.0.23.
Use Case :
- I import a custom male shape in both Avastar 1.5.9 and Avastar 2.0.23.- When I edit the bones like NECK or CHEST I notice that there Tail coordinates are not the same between the two skelettons
I really do not know if it is normal or not. I just raise here this difference in case it can helps to find if there is a problem...
-
I do not know if this problem has been raised before but it seems there is an issue with the export of Fitted meshes with Avastar 2.0.23.
Use case :
- Export a Fitted mesh (like a fitted mesh body) with an "old non Bento" Avastar and import it in SL : It is ok.
- Migrate this Fitted mesh in Avastar 2.0.23 (either by updating the rig or by unbinding/bind the mesh on the new aramature), export it and import it in SL : The mesh seems modified !You can see the difference on the picture below : In RED the correct and old export, in WHITE the wrong and new export.
Does someone else raised this issue ? Do I do something wrong ?
-
To Matrice and the Avastar team :
I have just installed Avastar-2 Alpha 5 and I noticed an issue : the eyes do not follow correctly the Eyes sliders anymore...
-
As human mesh heads creator, I fully understand the concerns of Mel Vanbeeck who tries to find the best compromise in order to combine both the animations and the sliders.
Because it is obvious that customers will want both and don't care about the technical constraints behind !
Of course, animations using translations (and rotations) are much more powerfull and beautiful.
I think we are all aware of that...But translations animations means no sliders...
So, if we find a way which allows to have nice rotations animations AND sliders for human mesh heads. I am 200% in favor of it !
But I must admit I stay a bit septic...
At the end, with all the rig improvements, will we be able to create proper rotations only animations for our mesh heads in prarallel of the use of the sliders ?We need to try to answer this question...
-
2
-
-
Thank you Vir for these details !
Indeed, as it is done, this will not alter the other meshes worn as the offsets (by meshes or animations) will be reapplied.
In any case, if I notice something, I let you know. -
Thank you Gaia. I will get this version... :-)
I noticed also a little "shift" between Avastar and SL regarding the jaw elements.
-
Thank you for your answer Gaia.
Regarding the Jaw position, that is exactly what I did.
I have adapted the bone position with the shape sliders in order to have it at the place I want before binding my mesh.
That is why, I am not sure we can say that the bone is not at the right place as it moves a lot according to the shape used...Regarding the Avastar features you described, I think I do not have the same version of Avastar as you because I have none of them.
I use the last public version : 2.0.10.Here is what I have in the Collada and Rigging panels :
-
If the animations to stop use translations, a "background low priority animation" can not solve the problem because this low priority animation will also lock the bones positions (even if it is in the default positions) and that is not what we want here : we want something that release completely the bones used...
From my point of view, this problem will be extremely annoying for the end users : they will wear mesh parts including Bento translations animations that will lock their bones at a position and the effect will continue, deforming their shape, even after detaching the mesh parts...
If they use the Reset Skeleton, will this not compromise the operation of the other mesh parts (using Bento translatons too) they may still wear ?
-
1
-
Facebook
Instagram
Twitter
YouTube
Flickr
Weird Glossines issue on once my normal map is imported in SL!
in Building and Texturing Forum
Posted
Indeed, I am suspecting a problem of compression at import... 🙁