OptimoMaximo

Not for long Very true! What's worrying is that they will let SL die first, in spite of it being their main income source.

Interesting, and i really would love to see that. However, the issue from my intervention still stands. You refer to code that reads/writes (upload) assets, that can be done using any programming language that supports C struct capabilities, even python. The issue at hand is more about changing that encoding architecture NOW in SL (breaking everything) or ADDING a new asset class with its own new encoding, or just a modified/extended child class.

I agree. As much as every possible feature you have listed in this thread are a wealth that, at the very least, i would label as "awesome to have", for Linden Lab, Second Life is a old son near to death, otherwise Sansar wouldn't be that money sink hole that all creators in SL are funding with the increased payout fees. SL has seen too much noobish development practices for anyone to be actually able to wrap their mind around it all and fix things. And there are too many other competitors onto virtual online platforms support for Sansar to see any success, @animats is right about it, with SpatialOS in the equation and also EpicGames trying to host online live events (they recently had a Fortnite map become a live concert platform with one million concurrent users online at the same time), someone will eventually get the right mixture to take SL's place. And, in my opinion, have Sansar go down the same route, considering the development habits LL is keeping.

And how does that exactly fit within the context of assets encoding? What you describe is another architecture issue, in which someone makes the system work using two different languages communicate together. The actual context of my intervention is how assets are being encoded, try to change that and everything (read: assets) would go bananas instantly, while adding more on top, like creating a new type of asset, adds up over an issue that sees the CPU not having much more wiggle room to handle things, as stated various times by Beq Janus in other threads.

Little note there, @Chic Aeon : the OP is about baking normal map and AO from an highpoly to a low poly model. What you suggest, in this case, is not possible because of that. Another course of action might be avoiding the treads completely and generating the same shape's normal map elsewhere, and then compositing it over and over on top of the flattened normal map (i would personally do it in Substance Designer, but Quixel NDO would do just the same), and when done, generate the AO from the newly created normal map.

I think you can override clamped sliders by double clicking and typing in your desired value. Besides, you can try to choose a different method than the Mitchell-natraval, which is one of those sampling methods largely used to retain crispy edges. In Maya i often use Lanczos but i don't know if that's available in blender. Otherwise gaussian is a good choice but it tends to blur pixels too much

it's most likely an issue with the number of weighted bones. Since Bento project was released, one of the requirements for uploading a rugged mesh is to remove the unused bone groups. I don't know what's the method to do it in Blender with a single button click, but it should be good to remove all bones groups from the spine up

did you try to increase the number of pixels for the antialiasing? 1 pixel like in your settings looks to be quite low, try with at least 2 or 3, otherwise it's pretty useless if it can interpolate across just pixels directly neighboring the sampled one

Call it religion if you like so, but certainly these "patronizers" aren't in the "closed club". If you ever participated in a Content Creators Group meeting, every single one that promoted good practices were shunned aside, myself included, to listen to and implement the craziest/laziest of the requests, for instance the animesh limit raised from 50K polygon to 100K limit due to the continuous whining of certain individuals (who were claiming "unlimited polys" at some point), while the "closed club" members (and i know in specific who you are referring to) were advocating for the initial limit to be fairly good and sufficient. Yes, i very much realize that. As i said, the moment that mesh went live on SL, the game changed. It might be true that people can keep enjoying building and creating, as you say they harm no one on the land they pay for, but the problem sits elsewhere. Let alone the rippers, but the marketplace is full of semi-sculpted models that, in the end, harm everyone bogging down sims where the owner placed such bought content. Why? Because "everyone does it and i have to too or i won't sell" basing off beginners (and ripped) content that was uploaded and merchandised as-is from whatever rendering application. And if you run into a game-grade asset, chances are that you will find comments like "it needs more work on the mesh. Looks like a video-game model". As if it would be a problem to subdivide that same mesh, slap a displacement map onto it and have it "more worked".

The Blender Foudation offers a wide array of books, among which the beginner can find a GREAT manual called "Blender for Dummies". From the "never heard of 3D modeling" status, all the basic concepts are being covered and, more importantly, they would contribute to Blender's development.

This is not always the case, but i can agree on the fact that the current status and the available assets contribute to make your statement true Indeed, game engines such as Unity and UE4 have an interface to declare what the distance from the camera needs to be for each LoD to kick in, not to mention that they can be custom models that don't even need to be derived from the LoD0 model or that have to have the same materials subset. If i wanted to set a sphere as LoD0, a prism as LoD1 and a Cube as LoD2, there's nothing that keeps me from doing that. Not optimal but it can be done. SL can't keep up with these standards change because of its internal architecture. Changing that would mean either break existing content, or add more code to differentiate between a legacy item and a new item. It's been stated countless times by now, by the firestorm devs present here on the forum, that there isn't much wiggle room left to have the CPU's running a SL viewer to handle more than what they currently do. This statement has nothing to do with what arctan project aims to handle. It's not a new item class or such, it's a formula to update/upgrade/improve the items costs calculations to be set in place of the current LI and Avatar Rendering Cost formulae. Therefore it will be applied as a global and it has no connection whatsoever to specific items, or the technique such items underwent during their creation. The same moment that LL deployed mesh as a new asset item to SL, the game changed. A substantial difference was set in place between the "before" and "after", which is the custom geometry. Whereas in the "before" SL had a set of pre-made meshes to work with, with their own LoD and texture system, the "after" required a higher skillset, a higher standard (the LoD auto generator...) and more control, in which the previous mindset for which the platform was intended to deliver an artist-free-from-optimization-worries environment had to fall. So, i stand by the thread title, for the beginners have to learn the basics of 3D modeling for SL-contemporary game environments, in which LoDs were to be made by hand and texture memory was a concern.

it is not on MP, to buy it you have to contact the creator in IM in world: polysail is the name

Marionette for 3DSMax is available for purchase only by contacting the creator, Polysail (Elizabeth Jarvinen)

That's an issue with collision volume bones not being set to the correct scale: they are obviously set to a bigr value than SL's default, therefore it appears to shrink the mesh down Your issue is less severe than the one reported in this older post It also depend on the software you're using, whether it supports bindposes or not. Your best bet is to purchase one of the available plug ins for the main 3D softwars: Blender: Avastar Maya: Mayastar 3DSMax: Marionette

Indeed, that's why I am taking a LONG break from teaching 3D modeling (Blender until a few years back, then Maya) at BuildersBrewery (and i think i will probably retire in the end). Most of the people i trained who continued to model, ended up doing the reverse of what i've been teaching to them: highpoly to the limit because "everyone does and if i don't, i won't sell anything because it's lower quality". The frustration this caused me over the years led me to drop completely any "advanced" class, sticking only to the basics. Why should i waste my time teaching how to retopologise an highpoly model, unwrap it and extract normal map, if in the end what i see it AT MOST a retopo'ed model, subdivided to a similar poly rate as the original, just shrinkwrapped onto the original model, so to catch the original detail? Not to mention those coming to class just for advice on how to get their free turbosquid model to upload to SL "i don't care to make models myself, there are so many out there for free LOL". The worst thing in all this is to see that the more unoptimized, polygon bloated, ripped off models available on the marketplace are those which sell the most, while the carefully crafted, real "original", made from scratch from concept to completion are relegated in a "nice, but not high quality" niche.

Figure that it is the same limit most game engines support. UnrealEngine4 and Unity have that same limit, for instance. Same goes with Bethesda's CreationEngine (Skyrim, Fallout franchises). The way to proceed is to think in groups of bones for a specific deformation. By this, i mean that you should think to achieve a specific shape by moving and rotating two or more bones at the same time, ideally creating a set of controllers that animate the bones via drivers (as Blender calls this feature). Here is a good tutorial to understand the idea Of course the shapekeys part is not applicable (that's why they wanted so many bones in the face), but at least it gives you the idea of setting up one controller to override multiple bones behaviors to achieve what i pointed out above.

ciao @beduino Ruben come dice motoko qui sopra, hai troppi poligoni nel modello. Ciò che devi fare é un processo chiamato retopology, vale a dire che devi ricostruire un modello con meno poligoni sopra alla superficie del modello iniziale proveniente da zbrush. Una volta fatto questo e dopo aver creato le UV per il modello lowpoly, potrai procedere all'estrazione della normal map e ambient occlusion derivanti dal.modello ad alto numero di poligoni proiettandoli sul modello a basso numero di poligoni. Queste sono le basi per procedere alla fase di texturing, che ovviamente avviene sul modello a basso numero di poligoni Edit: fra l'altro, nella finestra di importazione, in basso, il viewer ti dice che il numero di vertici è superiore a 65535, che è il limite massimo per la codifica di un modello in termini di vertici. Seppure è vero che ZBrush include di default i dati relativi al polypaint (che si dovrebbe disattivare in fase di sculpting per evitare che ciò accada), questo non inficia sull'importazione in SL in quanto il blocco dati ad esso relativo viene ignorato completamente dall'uploader.

see? There is already a problem with it: being full perms doesn't give you the right to export it as you don't own the IP. Full perms means you have a license to use the animation within SL for all possible uses, including resale of products containing such animation. most likely it came with a term of use where it's stated that you can't resell the full perm product "as is", which extends of course to the export/reimport, that is also IP theft being the animation uploaded under your name\account. I would suggest contacting the creator and ask for the same animation with the priority you need, in the first place.

If it wasn't made with the SL skeleton to begin with, the thing is gonna get a bit more complicated than that, involving a procedure called retargeting, admitting that this animation comes 1) in a readable format 2) with a Tpose. If one of these two conditions aren't met, the procedure gets a bit even more complicated with no guarantee of success or 100% accuracy to the original. There is also the issue of its origin and the applicable licensing: for example, Turbosquid provides animation files too but its ToS and License agreements forbid the use in SL.

From your screenshots i see that the PELVIS is the collision volume bone with problems. I've looked at the spreadsheet, and i find all of the bone scales completely wrong and in line with the misbehavior represented in your picture. See this screenshot, it shows the scale the avatar should have on PELVIS

Your list is quite complete, but i would summarize by type of beginner: - Want to make clothing with no clue about 3D modeling of sort whatsoever. - SL should upgrade to the (self proclaimed) "relevant standards" so that we can import anything with no restrictions / what's this BS called optimization

it's the third thread with the same question this week, why not looking for answers before posting?

in short:you need to pose the fingers too, in order to override slink hands animations

@VirtualKitten it's because it has collision volume bones, which in SL have a bind scale around the 0.03, which blender can't handle as it doesn't support bindposes and it assumes those bones scale to be 1 in all axis, reason why those bones scale down squeezing the mesh when trying to animate, indeed the clothing template comes with collision volume bones. Try removing the collision volume bones and the associated vertex groups, making sure it still deforms right for animation, and it should work as expected

Yes, it collapses like that because Blender doesn't support bindposes, and rigging a fitted mesh requires the collision volume bones to have specific scale values at binding time (which Blender doesn't support) So, basically, everything is working, considering that you've bound the mesh to collision volume bones with a scale of 1,1,1 and the collision volume bones are supposed to have something around 0.05 in all axis (each one has its specific value and they're not always uniform). Therefore what you see is a "scaled down bone" deformation, which squeezes the mesh inwards like that. The solution may be this: 1) research what all the scale values should be for each collision volume bone 2) add them to the appropriate bones as custom attributes/properties 3) Export using the SL/OpenSim preset, it should retain the custom attribute/properties, overriding those found on those bones