animats
-
Posts
6,180 -
Joined
-
Last visited
Content Type
Forums
Blogs
Knowledge Base
Posts posted by animats
-
-
Are there any problems with having an alt and a main account with the same email address? I just created an alt, and that generated an email from SL:
"Please verify that this is the correct email address for the Second Life account Animatsalt by clicking the following link within 24 hours:"
If I click on that link, a page for my main account comes up.
-
1975 called. Big hair and all.
Doing some work on a motorcycle and nobody was handy to sit on the back for testing. So I created an alt, which I've not done before. This is what I was given.
Come on, LL. If someone wants that look, they can get it, but no new user should be given it by default.
(By the way, when you leave the starting area, the new user experience HUD really should detach itself.)
-
6
-
-
A nice way to do this would be to move the diver, after they're done diving, to the base of the tower. (Better, near the base of the tower, with a random offset to avoid pileups.) Then they climb back up the tower (sit on something, get moved to top of tower while doing a climbing animation.) If the sit-on to climb object only has one sit target, only one person at a time can climb the tower. This will give you some traffic control while retaining free will.
Even better, after diving, the avatar should be able to swim. There are swim HUDs. (Is there a full-perm one you could mod into an experience?) Dive, swim, climb out, climb tower, repeat. Just like RL.
-
1
-
-
The RL standard (US OSHA) for railings is 1.07m. But SL avatars are so tall. The general idea is that a railing should be above the center of gravity of humans, so that if you ran into it, you would not go over. Works for avatars, too.
-
1
-
-
This problem has come back a few times. It's definitely associated with a disconnected vertex or triangle being used to mess with the size of the physics model. Discussed this with Chin Rey, and she gave me a door to try as a simpler test case.
Doors. There's a loose vertex on each so as to place the object's Z axis centerline at the desired hinge point. Standard SL door trick. These behave fine for collision detection, but llCastRay calls sometimes go through without detecting them. My NPC doesn't see them, and being keyframe animated, can go right through them. Results from my ray-casting tester are inconsistent - some ray casts go through, some don't. Need to try this with one of those imaging ray cast tools.
So it's not an inside/outside problem; even this simple object shows it. A loose vertex in "surface" physics mode breaks llCastRay.
-
1
-
-
Related Firestorm JIRA proposal.
More technical than the above discussion.
-
1
-
-
On 3/24/2020 at 12:25 PM, lucagrabacr said:
@Draxtor Despres just helped LL with recording some sample conference venues for businesses / organizations to see and use, actually. 🤦♀️
There's also "Boardroom" sim. Two conference center buildings, with medium-sized conference rooms for 10-20 avatars. From the prim era of SL.
The large-screen displays there all seem to be stuck on "Please Stand By", but that could be easily fixed..
-
1
-
1
-
-
If several people are watching media on a prim (big screen TVs, movie theaters) in SL, does everybody present see the same thing? Those things are really web browsers in the viewer. Are they locked together in sync somehow?
-
1
-
1
-
-
On 3/4/2020 at 11:18 PM, Kyrah Abattoir said:
It took me a while myself until it dawned on me that it's really just a per pixel gloss value, the same way we have per pixel environment.
In a PBR system it really is a gloss value. Unfortunately, in SL's system, the texture color and the specular color are added. This can take something all the way past 100% reflectivity, into full-bright territory.
Both wheels are high "shinyness". The one on the right is also full white diffuse. Under bright lighting, the one on the right saturates at full bright. It looks like a light source, because it's more than 100% reflective. If you add shinyness, cut down diffuseness.
One advantage of a PBR rendering system is that you don't get this effect. You never get out more light than you put in.
Under dimmer light, they look similar.
-
If someone is looking for an area in which to make good objects, consider wheels.
Missing something here? LOD factor 2.0, nothing special about the way the picture was taken.
Many SL vehicle builders buy wheels, rather than making their own. Most of those wheels have very poor lower LOD models. Far too many SL vehicles lose their wheels at distance. Looks awful. The vehicle above has a third-party wheel. Looks fine in close-up.
There are stores that sell wheels to builders. Those wheels are usually left-overs from the early years of SL. There's a motorcycle shop which has a parts junkyard out back. Few of those wheels look good at lowest LOD. At lowest LOD, the wheel should be a simple cylinder or hexagon with a picture of a wheel and tire tread. Wheels should be 1 LI objects.
We need better wheels in SL. They'd probably sell, expensively, as full perm items to vehicle builders. There are people selling wheels on Marketplace, but you can't tell if they're any good until you buy them. The in-world stores are often gone. I'm in the market for some better motorcycle wheels; if you're interested in doing something like that, IM me.
-
1
-
-
It might be worth approaching some universities about that. Stanford just told all their undergraduates "go home and don't come back. Everything will be online. Oh, and by the way, no tuition reduction for online-only."
-
Or, why there's bogus movement at region crossings.
First, this has nothing to do with region crossing failures. This is all about how it looks in the viewer on successful region crosses.
To recap: whenever a vehicle crosses a region boundary, there's a delay of about a second, sometimes longer. During this delay data about the vehicle, the avatars involved, the attachments and scripts involved, and some other data is packaged up by the sim server of the region being exited, transmitted over the network to the server handling the new region, unpackaged, loaded into the new sim state, and started up. During this period, the vehicle, avatars, etc. do not move at all.
The viewer tries to hide this pause with some fakery, trying to guess where the vehicle/avatar is going. This works well for walking, OK for slow boats, and badly for fast ground vehicles. Sometimes the guess is so bad that vehicles roll over, go underground, or fly into the air, only to snap back to their proper position as the new sim takes over control.
This effect is worse than it should be. Here is why.
As a test, I built a version of Firestorm which logs every object update message (sim to viewer) to whatever the avatar is sitting on. Then I made a few trial runs and graphed the results.
I'm on a boat. This is the velocity in Z (up and down) the sim sent the viewer, in meters per second. It's almost zero all the time. The big moves at the beginning are from getting the boat into the water. At a region crossing, the last velocity value before the region crossing is used to project, in a straight line, where the boat will go. No problem with that here. Smooth sailing.
I'm in a car. This is a trip around Robin Loop in Heterocera, starting and ending in Burns. Mostly good road.
On this little trip, using Firestorm with standard settings, the vehicle went underground several times at region crossings, and into the air once. Once you can see the Z velocity data, it's clear why. SL ground vehicles bump along as the physics engine slides them along the terrain. (Rolling is an illusion; they really slide.) Just as in real life, there's some bouncing up and down as this happens, and it's worse at joints between pavement sections. Nothing wrong with that. The physics engine in the sim process operates 45 times per second, and those little bumps get corrected very quickly.
Until a region crossing comes along. Then, the last velocity values (and angular rate values, not shown here) are sent to the the viewer, followed by silence while the region crossing takes place. The viewer tries to extrapolate those, for a second or so. Or, 45x as long as those values were supposed to be valid.
That extrapolation amplifies every tiny bump right before a region crossing into a huge move. Only the very last velocity value before the region crossing gets extrapolated. Any bumpiness in that last value turns into a huge bogus move, amplified by about 50x. As you can see from the chart, there are some big bumps in there. Some of this is imperfect road. Most of it is just the random result of the physics engine keeping the vehicle in contact with the road, which it does by applying a correction every 1/45 second.
That is why there is large bogus motion at region crossings.
Previous thinking was that there was some kind of bug involving the last object update before a region crossing. That's not it. It's a straightforward result of how the system works. Once you can see the data above, with those spikes, it's clear what's happening. If one of those spikes happens to be just before a region crossing, you're going flying.
So, what to do about this? My previous try at this led to "stop", or "don't extrapolate" mode in Firestorm. Drivers liked it because they didn't lose control trying to steer out of bogus motion. Sailors hated it because that sudden stop broke immersion. (Also, wakes and similar visual effects don't play well with sudden stops.) The "stop" fix stopped working in Firestorm 6.3.x, because LL put in a fix of their own, which still extrapolates, but not as much. That improved things for LL viewer users, and spread the misery around between drivers and sailors for Firestorm users.
For the next round, I'm looking at some kind of filtering to smooth out the noise, plus limiting the amount of extrapolation based on some measure of how noisy the data is. I'm trying some statistical tests on the logged data. More on this later. There's no perfect solution to this, but it should be possible to clamp bogus movement to something that doesn't make SL look broken.
-
6
-
-
2 hours ago, Selc said:
It seems these distant matte backgrounds could work for rendering the contents of distant sims. But the clientside calculation of polygons that generate these matte backgrounds needs to be hindered at certain distances. Currently, even the clientside calculations of polygons that generate avatar impostors aren't being shoved in a rocket and launched into the sun.
The idea is to generate them with some bot-like process that takes pictures and puts them on a public server, like the system that generates map tiles. Update maybe once a day. Skip isolated estate regions; you can't see them from a distance.The viewer would download one image and one elevation map upon which to paste it per distant sim, not all the objects in the distant sims.
-
1
-
-
2 hours ago, MyAlt4099 said:
Wouldn't that be easy using hashing though?
SL should do that as part of a cleanup of the uploading process. If you upload a mesh with textures, you should pay for each texture only once, even if you upload it repeatedly while debugging the mesh.
-
Everybody nearby can see what you're looking at.
-
How big a project are we taking about?
- US$0 to US$100 - don't worry about it.
- US$100 to US$1000 - copy some reasonable agreements from, say, the Nolo Press site, and get the other party to sign.
- US$1000 to US$10000 - talk to a local lawyer, do a background check on the other party. Maybe a deposit. Agree on arbitration terms.
- US$10,000 to US$100,000 - above, plus a better lawyer, formal contract negotiations, and agreement on what jurisdiction a lawsuit will be.
- US$100,000 to US$1,000,000 - above, plus in-person or video negotiations between your lawyers and their lawyers.
- US$1,000,000 and up - get a major law firm. It's going to cost, but it's worth it. (Been there, done that.)
-
1
-
SL has a long series of problems in the LOD area. One big one is all the assets with lower LODs created by the terrible mesh reducer in the uploader. The one that generates meshes with holes if pushed too hard. Then, the standard LI formula rewards extremely sparse lowest LODs. The combination of these problems is why you see so many things that show some random triangles at lowest LOD. Makes SL look junky.
This spills over into clothing. Much SL clothing partly disappears at the lower LODs. So, as a hack to fix this, all avatar clothing and attachment switch LODs at the same time, regardless of size. A highly detailed bracelet doesn't drop to a lower LOD until the entire avatar does. So avatars tens of meters away are still being rendered at full detail, even though the detail on the bracelet is now smaller than a pixel. This is the cause of much overload in busy sims.
There are better mesh reduction algorithms. They're great for weapons, vehicles, buildings, and terrain objects. Clothing, not so much. I tried using Blender's quadric mesh optimization on a hoodie for SL. It moved the edges of the fabric, rather than flattening out the wrinkles. That's because quadric optimization tries to minimize the volume error between the original and reduced mesh. For a very thin object, that goal leads to pulling the edges inward, not flattening a bump.
This problem is not seen in most games, because they don't have layered clothing that's not part of the character. So SL needs a solution that works for SL clothing. Mesh reduction for clothing probably needs to be done with a tool that knows it is working on clothing, and comprehends thin sheets. I'm not a clothing designer, and the clothing community needs to address that one.
Automatic LODs for buildings, terrain, vehicles, etc. should be do-able with the same technologies used in games. SL clothing, though, is going to be tough.
We do have avatar impostors. Set "number of visible avatars" to 3, and only the 3 nearest avatars are rendered fully. The remaining ones are only rendered four times a second, and shown as a billboard impostor, a flat picture. This is effective, but has display problems with some avatars and elaborate attachments, where the bounds of the object are difficult to determine.
We don't have general object impostors. There really should be a way to represent an object as a billboard impostor, a set of flat pictures where the picture shown is changed depending on the viewpoint. It's possible to fake this in-world, for one avatar at a time, with a flat object that rotates to face the avatar and changes the texture. This looks pretty good beyond 20 meters or so. I used to have an "impostor garden" in-world to demonstrate this, and many creators visited. Your lowest LOD would have only two triangles. Cheap and fast to draw. Downloading the pictures, though, takes network time. SL really ought to support this. Almost every game does. That's why you can see so far in many games.
I'd like to see impostoring taken to the max. Distant sims should be shown as sculpt-like objects with map-like images painted on them. That's what you should see beyond draw range instead of water. This could work like the SL map; have such objects for each sim, each 4 sims, each 16 sims, etc, used as you get further away. See for kilometers. With a tiny bit of blur and fog, you won't see the lack of detail out there. It would make SL feel much bigger. SL is a big world, but it feels cramped, because you can't see very far.
So, known technology could fix the drawing overload for general objects, but SL clothing presents unique problems.
-
1
-
-
Other than at LL infohubs, I've encountered few mean people, or even ordinary jerks, in SL.
Infohubs, though...
-
3
-
-
Just discussed at Server User Group. LL still working on this, but apparently mobile clients, at least initially, will not appear as an avatar in world. They can only do the things you can do from a distance - IM, group chat, voice calls, etc.
-
3 hours ago, KT Kingsley said:
To me, this suggests that the sim will recognise the text-only viewer and not waste it's time fetching and sending graphics data that'll only get ignored.
In the mobile viewer, what are you in world? A jellydoll? It's been a principle of SL that you can't be invisible in world; you have to show up in the list of nearby avatars. But if you can't see what your avatar is doing, controlling an avatar in world is not really practical.
-
If an object has pathfinding properties set, those are persistent, and survive copying, taking into inventory, and rezzing.
Easy to fix. Rez the object in world. Go to Build->Pathfinding->Region Objects. Find the object by name. Set its pathfinding status to "Moveable object", which does not put it in the navmesh. (It's probably "static obstacle" or "walkable") now. Click "Apply". It no longer affects the navmesh. Take it back into inventory and use that copy for further rezzing.
-
1
-
-
Yes. You can download "The Valley" and "Superposition" from the UE4 benchmark site. Those are interactive scenes; you can move around. "Superposition" takes a modern gamer PC, but "The Valley" will run on most machines able to run SL decently. I've recommended "The Valley" to people who suspect their computer has problems. If The Valley will run, the hardware is OK; if it won't run, repairs are needed.
Now, UE4 can do that because it preprocessing and optimization on the creator's meshes and textures before they get packaged as game assets. That's done by the UE4 desktop application. That's where LOD meshes are created, textures and normals are combined and baked, and game-quality assets are built. At a game company, the good artists create high-quality models without worrying too much about triangle counts, and lesser artists run the tools that crunch the meshes and textures down to usable sizes without losing too much quality. More of that is automated each year, by tools like Simplygon and AutoLOD. Full automation for that isn't quite here yet, but it's coming. Today, it's semi-automated - somebody has to supervise and adjust the parameters.
SL has only the mesh uploader, which doesn't do much, and what it does do, it doesn't do very well. SL is missing a step of the production pipeline, which is why so much bad content gets through. You can do all this by hand in Blender or Maya, as Chin Rey does, and get great results, but it's more work than with power tools. Some official Linden Lab "asset preparation" tools for Blender, plus fixes to the well-known and reported uploader problems, would help. You should be able to create in Blender or Maya, run the asset preparation tools, do mesh reduction and baking, and see what the asset will look like in world. The output should be one COLLADA file with all the meshes and textures. Upload and have an asset that looks the same in world, with only scripting to be added.
As for using PBR, Second Life has a diffuse texture, a specular texture, and and a normal texture. This is a subset of Principled BSDF, the default shader in Blender. Principled BSDF has the layers of SL, plus about 15 more optional layers. Few items use all those layers; the subsurface layers are used mostly for skin, the clearcoat layers are used mostly for auto bodies, and the sheen layers are used mostly for cloth. Second Life assets can be represented in Principled BSDF. Principled BDSF has become the de-facto standard for high quality content. It's used by Disney, Pixar, and Unreal Engine, and that's what you're seeing in "Superposition", above.
All this currently takes a PC with a modern graphics card to run well. But just rendering the diffuse and specular layers will produce the same results as current SL, so older computers can see newer assets with some loss of quality.
-
11 hours ago, lucagrabacr said:
Some newer things generally look nicer and are on-par with most modern games out there c= and try GEMC's cars and Bandit's / The Mesh Shop's boats, they make the best realistic cars and boats around
Yes. I'm amazed at the detail in some vehicles.
Getting the performance of SL closer to modern game standards is not impossible. It's tough technically, and would take considerable development and a larger dev team, but it's not impossible. I've written about this before. Speeding up SL is far, far easier than getting an SL-sized user base for a new virtual world. See Sansar, High Fidelity, SineSpace, etc. clearly demonstrate that. SL's world and content are valuable.
-
3
-
-
I'm getting strange failures from my NPCs at Brussiac. llGetStaticPath is returning an error status of 1000000, which is 0xF4240, which is documented as PU_FAILURE_OTHER or "other failure". I've never seen this status before. Inputs to llGetStaticPath are valid points within the region. Anyone seen this before?
My NPCs also keep ending up in an area locked out by an exclusion volume and not in the navmesh. May be unrelated or a bug of my own, but it's a new thing.
Facebook
Instagram
Twitter
YouTube
Flickr
Bellisseria 2 coming soon
in Linden Homes
Posted
Bellisseria 2? It's huge.