Wulfie Reanimator

Never let it be said I didn't do anything nice for you. Source: #define FIRST_LINK 1 #define W 16 #define H 16 #define MAX_ITER 256.0 vector cmin = <-2, -2, 0>; vector cmax = < 2, 2, 0>; vector offset = <0, 0, 0>; float scale = 1.0; adjust_scale(float factor) { cmin *= factor; cmax *= factor; scale *= factor; } float iterations(vector c) { vector z; vector next; integer i; while (i < MAX_ITER && llVecDist(z, ZERO_VECTOR) < 2) { next.x = (z.x * z.x) - (z.y * z.y) + c.x; next.y = (2 * z.x * z.y) + c.y; z = next; ++i; } return (i / MAX_ITER); } render_mandelbrot() { // Little fake "screen refresh effect" llSetLinkPrimitiveParamsFast(LINK_SET, [PRIM_COLOR, ALL_SIDES, <0.1, 0.1, 0.1>, 1]); integer x; integer y; vector c; for (y = 0; y < H; ++y) { for (x = 0; x < W; ++x) { c.x = cmin.x + (x / (W - 1.0) * (cmax.x - cmin.x)) + offset.x; c.y = cmin.y + (y / (H - 1.0) * (cmax.y - cmin.y)) + offset.y; float iter = iterations(c); llSetLinkPrimitiveParamsFast(FIRST_LINK + (W * y + x), [PRIM_COLOR, ALL_SIDES, <iter, iter, iter>, 1]); } } } default { state_entry() { llRequestPermissions(llGetOwner(), PERMISSION_TAKE_CONTROLS); } run_time_permissions(integer perm) { llTakeControls(0 | CONTROL_UP // Zoom in | CONTROL_DOWN // Zoom out | CONTROL_FWD // Move up | CONTROL_BACK // Move down | CONTROL_ROT_LEFT // Move left | CONTROL_ROT_RIGHT, // Move right TRUE, FALSE); render_mandelbrot(); } touch_start(integer n) { if (llDetectedKey(0) == llGetOwner()) llReleaseControls(); // Freedom! } control(key id, integer hold, integer press) { if ((press & hold) == FALSE) { return; // Early exit for frequent hold/release events. } if (press & CONTROL_UP) { adjust_scale(0.9); } else if (press & CONTROL_DOWN) { adjust_scale(1.1); } else if (press & CONTROL_FWD) { offset.y += -1 * scale; } else if (press & CONTROL_BACK) { offset.y += 1 * scale; } else if (press & CONTROL_ROT_RIGHT) { offset.x += 1 * scale; } else if (press & CONTROL_ROT_LEFT) { offset.x += -1 * scale; } render_mandelbrot(); // After every input! } } The "screen" is made up of 256 links, Second Life's maximum limit for a single linkset. Doing that by hand is extremely tedious, so I used this script to create a correct grid after I linked 256 cubes together: default { state_entry() { float s = 0.1; // Short for "size" per cube... llSetLinkPrimitiveParamsFast(LINK_SET, [PRIM_SIZE, <s,s,s>]); integer y; integer x; for (y = 0; y <= 16; ++y) for (x = (y != 0); x <= 16; ++x) if (16*y+x > 1) llSetLinkPrimitiveParamsFast(16*y+x, [PRIM_POS_LOCAL, <(s * x - s), 0, (-s * y)>]); } } P.S. The above script reminded me of how much I absolutely hate the link numbering in SL.

Are you able to make the sign in 2D and show it here, since you have the 'font and colors and stuff?'

Oh, okay. I assumed you had prior knowledge of seams existing. The thing about LL creating "better" light presets is that there isn't a universal solution that looks natural (especially with a day cycle) and avoids those seams. Gabriele's image for example has basically no shadows at all (or rather, everything is in shadow -- no contrast). It's overcast weather, which is fine, but should we replace our default midday/night/evening with overcast versions? I think a world without shadow looks very artificial. You could try to change the angle of the sun, but that would stop working as soon as the avatar moves a certain way. P.S. The body fat thing doesn't fix "seams" unless there's an actual gap in the neck between the head and body, and even then you have to be lucky, and you'll probably still be left with visible texture seams.

What I'm still scratching my head about is, how is this relevant to this thread? Creators have been including notecards about "light settings" for literally years. Why are we talking about it?

How many scripts are you dealing with exactly? This system seems a bit... cumbersome.

Downside to this is that if you don't have Advanced Lighting Model enabled, you just see multiple stacked point lights, which are proportionally brighter and probably ruining the immediate surroundings.

I'm posting from my phone so I can't easily find a link to the image I've posted before (recently), but you can create one from your inventory by creating a New Clothing > Universal. Basically, it has a slot for every avatar texture, plus 3 "aux" slots that don't normally show on an avatar unless a script enables them on an attachment.

BOM does "put all those textures into one texture, but for each section of the body separately. BOM still has a separate texture for the upper and lower body, but BOM allows you to wear something around 60 layers of "upper body textures" as a single upper body texture. BOM is not only about tattoos. It works with all wearable types, including the new "Universal" type that didn't exist before.

LSL can easily run a raycasting engine like seen in Doom or Wolfenstein. One example can be found here, although it only has player movement and static walls. It's only one script, too. LSL has all the elements it needs to fully run Doom (heck, you can run Doom in Factorio using 2.2 million items on conveyor belts), just nobody has done it as far as I know. Running an OS... I don't think that's feasible even if you had the skill and time to create it. One of the biggest problems there would be that scripts don't have a cheap way to render things. LSL is very slow, and very low on memory. Edit: And of course, if you want to cheat like Minecraft did, yes, you can run Doom via the built-in browser.

Ok, then we don't disagree. Great!

I did read what you said, and I have re-read it again. "A downside with BOM skins is that you have to change your lighting or you will get a neck seam." As opposed to... not using BOM skins? This statement clearly implies is that "neck seams are a downside of BOM skins." Is this not how the sentence structure in the English language works? (I'm not a native speaker, do correct me if I'm wrong...) If BOM was not the cause, why would specify BOM? Why not say "downside with skins?" But at that point anyone should tell you "yeah, we've always had neck seams" and pointing it out now is kinda redundant. The fix doesn't depend on LL or the way lighting is rendered in Second Life. I haven't used EEP yet, but with classic Windlights, you can get rid of shadows (seams) by setting the "Sun/Moon Color" to black, and reducing the Ambient color to a darker grey to control the overall brightness of the world.

Well, no, there's no amount of texture-perfection that can fix mismatching normals between the two objects. Try it with a blank white texture. This should be perfect but you'll still see a seam. This could be fixed if the creators of the two different objects collaborated and shared the connecting areas of their models, so one could manually match the other.

BOM has no effect on neck seams. Neck seams are caused by two things: Mismatching textures. Obviously, if they're a different color at the seam, you'll be able to see the seam. Lighting, or more specifically "vertex normals." Essentially, shadows are created based on the surface of a mesh. The further away a surface is facing from a light source, the darker it is. This works well with a single surface, since all the "points" of that surface are connected to each other. But the "neck seam" is actually where two separate objects connect. Their points may be at exactly the same location, but their "directions" don't align because they aren't connected or properly aligned. The result is that the top-of-the-neck gets different shadows from the bottom half and you see the seam. This would happen regardless of whether you're using BOM or non-BOM textures. A creator making a claim that BOM causes seams simply doesn't understand what they're talking about. Changing your lighting to CalWL or similar will make the problem go away because they get rid of shadows altogether. It's similar to setting your head and body to fullbright. It's the same kind of "hiding the problem under the rug" as increasing your LOD factor to 4 instead of seeing mesh degrade into triangles.

Group chat has never been "fixed" in the sense you're talking about. It always has (and always will) have spotty issues. The thing Linden Lab fixed was only one specific issue, but "working as usual" is far from perfect.

I recall that reason being that sculpts were always using the same amount of verts/triangles based on the resolution of the sculpt map (texture), which can be seen as wasteful. But the resolution of a sculpt map is way below the amount you'll see in basically any user-created mesh object, so I would discard that as a valid reason to dislike sculpts. Sculpts do have their upsides, especially more coherent auto-LODs, I just don't(/didn't) know of a good way to make them.

As discussed in that other thread you linked, if you're correctly using sit targets, physics occlusion won't matter.

How many links does the linkset have, and how many sitters should it have? How are you "updating" the sit target? Can you show the script? This shouldn't be complicated.

If that's all you took from it... I'm sorry.

In Second Life, you can't exactly "link two things together, then link them to something else" in a meaningful way. The two linksets become one, and the doors can no longer tell which prim is the "hinge" that used to belong to it. For this reason, a rotating door that is part of the building itself needs to be handled differently from free-standing ones. Rolig's example is great, but it won't work once the doors are linked to anything else because the link numbers will change.

Theoretically speaking, both could be faster. It depends on how the compiler translates it. Case 2 could be slower because we know for a fact that conditions are fully evaluated in LSL. if "press == nametag1" is true, the other two are still checked. The if-else chain could create a "jump table" or even optimize the order of the conditions so that the "most common case" is assumed before any checks, but I don't think we know how the LSL compiler handles these. I don't think we even have any way to access the compiler either, since scripts are compiled server-side. I'm of the opinion that things like this is not something you should focus on, because the decision to use case 1 or case 2 is not going to be noticeable at all, compared to the readability and what the code implies. If you have 3 different cases that all lead to the same result, you shouldn't separate them like in case 1. That's one way to set yourself up for bugs and duplicated code. (And since we're on the topic of micro-optimizations, that duplicate code in case 1 is going to cost you some memory.) But it would be interesting to know from a technical standpoint.

Without an ongoing list of creators that do this and with no ability to blacklist creators and their shops on MP, if you aren’t a gamer it’s harder to avoid this. I know I don’t recognize a lot of ripped game stuff unless it’s pointed out (I do ask gamer friends if I suspect things are ripped) or I try my best to look it up because I’ve never played very many games. Ditto for 3rd party imports that may or may not be used in SL against the original creator’s TOS, though often those are easier to look up on 3d sales sites by descriptive keywords. If it’s a very obvious thing like Disney, sure but otherwise? I’m iffy. Avatars made for Second Life tend to have a specific "flavor" to them compared to ones made for other actual games. We can discount avatars that would be considered "recognizable game characters" and there'll still be many quirks that are obvious tells about whether something is exported from somewhere else and not made with Second Life in mind. It's obviously not something everyone can do, but the more time you spend looking at the types of models people make for Second Life vs 3D modeling software vs actual games, you'll start to quickly recognize that "something doesn't belong." For example, this is a recent upload in the Complete Avatars category: Just the way this item is titled + its description is a red flag that this is just a quick upload from somewhere else and not a "real product." If I do an image search for "final fantasy 8 squall chibi 3d model," you can quickly tell that this is just a model that's floating about the internet, and the original comes from "Itadaki Street Special" which is a PlayStation 2 game. Another example: First, let's ignore the ridiculous price. Something seems off from just looking at the texture quality. Avatars in Second Life are the main attraction and what people spend most of their time looking at, but you can almost see the pixels in those textures. Nobody would make an avatar like that for Second Life, even if they wanted to make a low-poly stylized avatar. Someone who has the skill to create a complete avatar like this simply wouldn't ever sell it the way it is, for as cheap as it is. The reason why this avatar has such wonky looking textures is because it's ripped from a game called League of Legends, which is a top-down action game and doesn't need that high resolution. And this kind of stuff makes up the vast majority of everything in that category. If you find one suspicious avatar, look at the creator's store. What you'll most likely find is a mish-mash of completely different styles of avatars, so different in quality (and in such quantity) that there's no way a single person would have created all of them. If we went into the price category that I think would at least be reasonable for a "complete avatar" (1000 - 5000 range), you'll see more of the same alongside the really good products. Reasonable price, detailed description, creator's name isn't suspiciously random, and their store looks consistent. Looks like a real product. Reasonable price, realistic description, lots of screenshots + features ("a lot of effort"), but looking at the store, it's one of those mish-mash cases. The scripted features can be pretty much copy-pasted between avatars, especially since this store seems to focus on combat stuff. The mesh avatars themselves however look very "default" or low-detail as if taken from somewhere else. I would almost guarantee they're all ripped. TLDR checklist: Does the product lack a description and screenshots? Does the store have products with greatly varying quality? Does every product lack a demo and inworld location? Does it look a bit too "low quality," like compressed/low-res textures? Does the quality of the avatar seem inconsistent with the product image? Does the price seem "too good to be true?" Does the creator have a generic name like Woodoo862834?

If you get to a point where you have a "finished" model to give us an idea of its size/complexity, I'm open to helping with advice to get the LI down. I find it to be generally easy to keep LI very low even with custom LODs (so things don't degenerate into loose triangles), as long as it isn't a very large (10-20m+) object.

If you like characters ripped from other games, go wild.

Is there a reason why you couldn't do the same thing with mesh? That said, I've tried getting Blender to export sculpts or at least dae that are compatible with older sculpt programs, but no success.

I mean, a name change is a name change. There's a decent enough mix of "names and non-names" in there, you're not forced to pick a silly one if you were to change your name. This is also not the first batch of names. The first batch infamously had the last name "Covfefe" in there. I think this is either the second or (less likely) third batch.