Jump to content

Da5id Weatherwax

  • Content Count

  • Joined

  • Last visited

Everything posted by Da5id Weatherwax

  1. Let's face up to one unpleasant fact. Those of us that successfully sell "products" in SL are pretty good at peddling snake oil. We have to be in order to make a go of flogging the intangible for what is equivalent to real money, for all the legal nicety that the L$ is an "in-game token." I say this not as a criticism, but from the honesty born of having been moderately successful at doing it in the past. Most of us have encountered situations where we can achieve the effect we want but our skills and knowledge are only up to doing it in a way that isn't "kind to the machine" and we are salesmen as much as we are artists so if we can talk that up into a feature rather than a detriment, we tend to do so. I know I was guilty of that on a couple of occasions. My knowledge and skills have improved since then and I'd hope I would not fall into that trap again but if all were being honest I think most would admit to at least a few instances of it in their history. And because we are good at peddling snake oil, folks buy into those sales pitches. You see it in software too, horrible kludges being marketed as a feature until even developers that know better have to hold their noses and implement it to stay competitive. You will never convince folks that have bought into it that way that it's bad so consumer choice will never fix this. That's why LL have to if it's ever going to change. They just don't think that the pain it will cause to the userbase is worth it, so they don't do it. They don't even incentivize merchants and creators to make improvements in this regard for new products, let alone update older ones. Without both the stick and the carrot, way too many of those merchants and creators just ain't gonna change what they are doing.
  2. All this back and forth about the subjective "quality" of optimized content versus builds/avatars where optimization has not been done misses a fundamental point. And that point is that a straight visual evaluation is subjective. It's also misleading. Folks are decrying optimization as "looking worse" - when the "poorer appearance" is just as likely to be disliking the creators chosen aesthetic as it is a consequence of poor or overzealous optimization. It's perfectly OK to prefer one creators style over another's - that variety is something that makes SL what it is. But both could be equally optimized - you'd still prefer the one over the other but it would perform better! Textures: At the closest normal range to view an avatar - say a fairly close-up portrait - or viewing a non-avatar build from a similar distance, any texture resolution where you've got multiple texture pixels in a single screen pixel is too high. It can be reduced without changing what appears on your screen at all. The appearance will not change in the tiniest amount from making this optimization. Your screen cannot display any higher resolution, so feeding it with a texture that has that higher resolution is a waste of VRAM and a cause of lag. This is not even a "best efficiency" optimization, that would be to set the cutoff limit where 1 texture pixel = 1 screen pixel at the most common distance to view the avatar or object - which would result in textures that were smaller still and unlike the "closest normal distance" optimization you would notice it in close-up shots. Nonetheless, it's still more optimization than most SL creators do. Most SL avatars and objects you'd have to have your camera pressed right up against the clipping plane to get 1 texture pixel to 1 screen pixel, if indeed you ever could. But when an optimization can be proven to make no difference to the displayed image - simply because of the display resolution compared to the resolution of the displayed texture - you can't claim it detracts from the quality at all. If you think it does you're simply wrong. Polycount: Particularly for avatars, this one is more awkward. It is undeniable that where an avatars skin must deform, around joints for example, a higher vertex density and therefore a higher polycount makes that deformation smoother and more natural looking. But when you look at an arm and see that there's no discernible difference in vertex density between the areas around the shoulders, elbows, wrists and the areas in the middle of the upper arm and forearm then that's a badly unoptimized model. Period. Nobody is saying "You have to make your avatar look like crap as soon as it gets animated" - that isn't what optimization is about. It's about not putting in complexity that you actually don't need and will never see any visual improvement from. A higher vertex density around the joints is (mostly) fine and does give better, more natural-looking movement with the same animation. Way too many creators in SL just increase the vertex density everywhere to achieve this - it's easy to just add a subdivision factor to the model, after all - and then get all bent out of shape (ironically) when they get told their av is a lagmonster or they pitch a snit when somebody points out their creation looks solid in wireframe view, often claiming that it's that way because it's "high quality." This last is particularly pernicious because a user that has spent time and effort on their appearance will frequently pick this up and actually go shopping for these horrible things in the mistaken belief that it "looks better" And because they've told themselves that it does, then the Emperor's new doublet looks just fine.
  3. The principled shader works pretty well, so long as you're not playing clever games with the alpha channels in your materials. HOWEVER... The place where you're going to have a seriously hard time getting "SL like" display of your materials in blender is specularity. The principled shader is PBR based whereas SL shading is not.The biggest "gap" between them is with the PBR parameters for specularity in the principled shader and the modified phong used by SL.
  4. ^^this. For this reason alone it's often a good idea to start by making your highest LOD model - or even an "insane LOD" model with details you'll later bake as a normal map - first. And then unwrap it before you start removing detail to make the LOD models you upload. Get rid of the details in blender by "dissolving" them rather than "deleting" them to make a lower LOD model - that will not destroy your UV layout so long as you make sure to not remove any UV island seams. Zap a seam and your UV mapping goes to hell in a handbasket, because you'll then have a "face" made up out of vertices from different islands which will not conform to your layout. Adding detail after unwrapping will usually result in a UV map that is not compatible with the lower-detail one - to the extent that blender will barf if you try and bake normals from one to the other, for example. To maintain compatibility the unwrap has to be done at the highest level of detail and then you keep that same UV map while making the lower detail models out of the more detailed ones.
  5. Think of the surface of your model laid out like a sewing pattern or a pepakura project. All the surface unwrapped and laid flat. Then you do the puzzle to fit them as efficiently as possible into the frame of the texture image - the parts of the image inside the pattern pieces are what appears on your model. Making that pattern layout is what is meant by "UV unwrapping" the model.
  6. This is incorrect. A point light created in this way NEVER casts shadows. That's why it shines through walls. The only things that can cast shadows in SL are the sun/moon and projector lights. Objects with the light emitting property and no projector texture set as you refer to below are simply a ranged light source with no consideration about whether that light is occluded by anything and no participation in generating shadows. You can't set "everything" - the most you can choose is "sun moon and projectors" - light-emitting objects without a projector texture will still never cast shadows even at the highest setting. Not even in Black Dragon, which is my regular viewer. Shadows == "none": Daylight and moonlight come through your roof and walls lighting up your interior. Projector lights pass through objects, lighting up everything to their max range. Point lights pass through objects, lighting up everything to their max range. Shadows== "sun/moon": Daylight and moonlight don't pass through roof and walls -You will need to light up your interiors. Projector lights pass through objects lighting up everything to their max range. Point lights pass through objects lighting up everything to their max range. Shadows == "Sun/moon + projectors": Daylight and moonlight don't pass through roof and walls -You will need to light up your interiors. Projector lights are occluded by objects and cast shadows. Point lights pass though objects lighting up everything to their max range. When building and designing you should always plan for all three, because you don't know how the user seeing it has their viewer set. To account for lower graphics settings you will want to bake in a small amount of light-based shading, but any time you bake in more than a little ambient occlusion shading you're making your object look worse at higher graphics settings which is probably not what you intend.
  7. Well, you can write perfectly functional code that is acceptable to a c++ compiler without declaring or using a single object. Of course, you'd actually be writing vanilla c....
  8. I like the way you think, animats.... And while they are at it could they please give us a working regex engine? We actually do at least as much string handling as math in a lot of LSL use cases and that's a huge hole in capabilities.
  9. Of course not. The Old Ones think they are delicious!
  10. Argh - 5am my time. - and right after a Friday night when I'm usually out late - either playing a RL gig or partying with buddies that do have a gig to play... No promises but I might be able to make it, since for me the blues is a bonus not a detriment
  11. "But colleges don't teach LSL..." Of course they don't. They don't teach shell script or perl either. They don't teach Haskell, they don't teach whatever language... If you think your college is teaching you "a programming language" you are missing the point. They are teaching you to think like a coder - how to break down the process you wish to automate into generalizations that can be formalized and defined in A programming language, not necessarily THIS programming language. If you can code, you can look up the syntax to write that code in any language. If you can't it doesn't matter how many languages you know.
  12. I left it many years before posting anything here, I guess it's time. I'm an older guy in RL, as well as in SL. I crawled into this virtual environment with a few of my colleagues at IBM back in SL's early days when a bunch of us were logging in and working out how to make cool stuff here. Big Blue's corporate presence sorta evaporated, but I stuck around. I'm not a mainstream merchant or content creator, more like the obnoxious gremlin lurking in the shadows picking at the limits of what you can make with SL tech and making horribly amateurish attempts at converting my wild ideas into virtual reality. I've a few avatars, each one very much an aspect of "me." As an example, as an IBM "corporate drone" I would usually walk around the grid as a borg in a business suit. This led me into Star Trek RP and as a RL trek geek of course I made my back-story borg-based. This gave me an excuse to wear any appearance in SL that I wished (once I'd RP-ed up an excuse to have a handy hologenerator) and remain "in character as me" I've made stuff, sold stuff, bought stuff, had a lot of fun here and I continue to do that. These days I mostly hang out with the furry communities as an anthro feline and spend several hours a week streaming live music into whatever venue I can fool into giving me a slot I am also using my RL experience in the music and entertainment biz to be part of the management team at a SL club and loving every minute of it
  13. While I agree that this is WAY overused, I think there's room for debate over the use of setting LOD factor to 0 to demonstrate it. In most cases you'll be viewing LOD0 a lot closer and more prominently on your screen than they would ever be rendered with a default LOD factor. If a user with graphics set low can pull back the camera from an object and it doesn't decompose until its a small blob of pixels with no discernible detail anyway, then wouldn't the creator be justified in zeroing that lowest LOD? Now, under those circumstances its very likely that LOD1 is probably more detailed than it needs to be and maybe they should make an impostor for that LOD while still zeroing the lowest but really, isn't the only honest test to cam back and watch how gracefully - or not - it decomposes rather than saying "show me the worst LOD way too close "
  14. Those standards are, at best, artificial and they really aren't the "best" for some people. It's arguable that they aren't even a good "average" but they are what we got so we live with 'em. Take a trip down memory lane to a time before Apple and when pretty much the only Microsoft product was MS-DOS, a command line operating system that, at the time, was clunky even by the standards of the then-current tech. There was a GUI system though, the brainchild of Xerox PARC and called X. Its descendants have managed the GUI on every unix and linux machine ever since. Unlike the Apple interface or Windows, though, it was never monolithic, never intended to be. Don't like how a particular window manager behaves? Want a feature that is only implemented in a minority version? Fine. Configure your login to use the one you want. Want different shortcut keystrokes for different things? No problem. Change your config files. What made a particular setup universally hailed as "good" wasn't that it was ideal right out of the box. The "best" implementations were always the ones that were most configurable, that no matter how you wanted to use it, you could set it up to be used that way. This was reflected in the software written to use it. Everything was usually configurable. Some people liked left button select, some people liked middle button select or right button select or some combo of a button and one or more modifier keys. And they could set it up that way. What you got "out of the box" was how the guy who coded it liked to work with it and if you wanted it different you could make that happen. Blender is like that. You've ALWAYS been able to set up its UI the way you want, to change the functions of every keypress or mouse event to make the actions you're familiar with do what you're familiar with them doing. That's hard on the folks making video tutorials though, or their intended audience. If everybody has their blender install configured with different controls this particular tutorial medium becomes less useful so all the reference material assumes the controls have not been reconfigured - and blender's UI came to be viewed as "hard to learn" instead of "easy to configure"
  15. I'm not an IP lawyer and in this scenario or one even remotely like it you'd be best served by consulting one. But, having been involved in IP issues professionally in my "day job" my guess is that unless you were marketing an avatar that looked like the Disney princess or a dress that looked suspiciously like a costume she'd been drawn wearing you could argue that since it is in an unrelated market and is a common feminine name that you are not infringing the mark - but that would be something you would have to resolve with the Empire of the Mouse before LL let you put the product back. Trademark beefs aren't like DMCA takedowns where the moment you counterfile they have to put it back unless an actual lawsuit is filed. If there's a trademark dispute it has to be resolved before the supposedly infringing product can come back and that resolution is entirely between you and the mark owner, LL are just spectators. Edited to add: Copyright and trademarks are very different beasts, and trademarks are the big freakin' deal for corporate IP departments. To put it in terms appropriate for the context, you've ridden into an MCs turf wearing something that they think looks too much like their patch. Now, you might not agree with that opinion but....
  16. A good rule of thumb is that as soon as you use anyone elses trademark ANYWHERE in your ad or use a trademarked logo, you WILL lose a trademark lawsuit and, sooner or later you WILL get a cease-and-desist from the trademark owner, as soon as they become aware of your products existence. You can make "basketball shoes" in SL, but if you put a star logo on 'em or call 'em "high top basketball shoes" you can expect a takedown from the Converse brand. So you don't say "Harley style", even though H-D is the most widely known brand manufacturing that style. You instead talk about "cruisers with the v-twin engine format made iconic by so many classic American marques" - you've drawn the comparison without imitation and further insulated yourself from trademark dispute by both using generic terms and highlighting that the "style" is not a "single brand" thing. Then you put YOUR logo on it, not theirs, making sure that you don't use common elements - like the eagles wings in the H-D logo, for example - or even stray into using a similar font for any lettering on the logo
  17. I can see just off the top of my head, at least four motorcycle trademarks in your keywords, at least one of which is owned by Harley-Davidson. Lose 'em. Lose any reference to "Harley Style" too, because you're implying that your product is in imitation of the trademarked one. This isnt copyright that would involve the DMCA, this is trademark infringement and they HAVE to pursue it, because if you fail to protect a trademark you can lose it.
  18. rez a box prim inworld. Scale it to fit the bounding box of the piece you want to make in blender. Note its dimensions in the edit window. If the mesh you make in blender has the same dimensions in the right-hand data bar with scale showing at 1.0 in all axes (which it will after you apply scale), you can upload it as-is and it will fit that same bounding box.
  19. Here's a somewhat involved workflow in your 3d prog of choice that will give you a consistent view out of all windows. Begin with a mesh sphere, normals pointing inwards. map its UVs using the same geographical projection used for background HDRIs in rendering. Use such an image for your texture, suitably downscaled for SL, of course. Now, for each aspect for which you have facing windows, take that sphere *at zero rotation*, copy it and delete the vertices that would make up the "inside half" when looking out that particular set of windows. Upload the hemispheres for each aspect and stick them on the outside of your windows. Make sure they are all the same size in SL. Apply your texture to 'em.The view out of each window will be different but will combine to a consistent 360 view. because the UV for the undeleted vertices will take care of rendering the right part of the texture on each one. Edited to Add: Something was bugging me about the above description and I realized what it was - it's been a while since I made one of these and so I made a test piece on the beta grid to confirm... Projecting a full hemisphere outside each window is too much. For an individual window it looks fine but if you can see two windows at different angles you see duplication. You want the individual "pieces of the sphere" outside each window to be about a 120 degree horizontal angle of the original sphere, but distorted - AFTER you equirect project and trim - in blender, or whatever prog you use, to be a hemisphere - and therefore cover the full field of view outside the window - when uploaded. Leave the vertical as a full hemisphere, minus the poles of course because you really cant uv-map a pole in an equirectangular spherical projection, the math goes to infinity. Some folks map the ring of tris around the pole separately and collapse them to degenerate point on the UV map but I just delete the poles from the original sphere. Unless you cam right up to the window while looking vertically up or down, you'll never see the hole.
  20. And this is another area where a skilled content creator at the Lab could make a huge difference. They could make "something" - and it doesn't really matter what - in two versions. One optimized and the other demonstrating a few of the more common gaffes in this regard present in current content. It could be demonstrated that one doesn't look bad compared to the other, that one loads faster, causes less strain on the viewer etc. Heck, they could even be rezzed side by side somewhere so that folks could go and look for themselves, with their viewer running their settings. But because they are NOT the product of any established SL creator but made as a demonstration by a LL employee, they are also not naming any names and thereby, quite understandably, getting creators backs up.
  21. Now this is how discussions on optimization should be... Respecting each others expertise, acknowledging that we have different "specialities" so we naturally end up with our own particular hobby-horses and areas where others may have greater insight. If this is ever going to be properly addressed it will take all of us, all our respective insights coming together.... We all love to roundly castigate the Lab, of course, but if we continue having a productive and respectful discussion like this I would bet that at least one or two Lindens will be reading it with interest and paying attention to any possibilities we uncover.
  22. We haven't always agreed exactly in this discussion, Coffee, but on this you nailed it. I can read the javascript (and OMG what a misbegotten bastard of a language, but that's another discussion) but I don't. Like every other SL resident I just use the page. if it's inefficient to the point that I notice it, I might in a moment of idle curiosity dig in to find out why but usually I'll just shrug and say "damn, another site that was coded by folks who think 7 layers is a cake" For the folks who "think it's cake", it's on the baker what they are eating.
  23. If you're planning on distributing a model for folks to retexture themselves starting with just a UV map, you have to at least make a nod towards making that easier. Hence the minimizing of distortions at the expense of efficient area usage. If you're making all the textures yourself and have the raw model in your 3d prog of choice you can do better. Maybe even - I don't know, what's the word? Oh yeah.. optimize it If you're going to make that trade-off to make it practical for other folks to - for example - make skins for your body then that's fine but be honest about it being a trade-off for that rather than bolstering the folks falsely claiming that unoptimized "looks better" "Badly optimized" always looks like crap, "unoptimized" always runs like crap. Properly optimized does neither.
  24. No, that reason would be that the ripped content was optimized for that particular game engine, not for SL. As such it is far from optimal when rendered as a SL asset. The general principles Penny is talking about are just that - general - and common to "optimization" no matter what you are optimizing for, but the finer details of exactly how to put those principles into practice are specific to a particular engine and render pipeline. A game engine that uses both normal and displacement mapping, for example, would need different optimization than SL which has the former but not the latter - and a model optimized assuming a displacement map was present would look like trash in SL.
  • Create New...