-
Posts
666 -
Joined
-
Last visited
Reputation
1,039 ExcellentRetained
-
Member Title
Canuck
Recent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
-
Lining up the neck seam between the torso and head for a new mesh body
Jenna Huntsman replied to Eoul Derryth's topic in Mesh
I think these images demonstrate that the Catwa head in question is using a nonstandard (or at least, not SL Neck) neck, as the Logo heads and Reborn use SL Neck by default (Not sure about Legacy, although I'd guess they are using SL Neck). Bonus with SL Neck is that it also resolves the seam issues caused by misaligned material maps, which is even more important with the introduction of the PBR viewer as the easy ""fix"" (not a fix at all actually, but one people keep reiterating) to turn ALM off is no longer available. -
Lining up the neck seam between the torso and head for a new mesh body
Jenna Huntsman replied to Eoul Derryth's topic in Mesh
You may also want to compare your body with a LeLutka head, as they originated the standard that most bodies and heads use now, called the "SL Neck". Not sure if there's a standard document or anything, but if you contact the LeLutka devs they might be able to point you in the right direction. -
Go back to basics for a second - Redeliver your body and head. Unpack the fresh copies, and wear them. Is the seam still visible? For example, my partner wearing the latest version of Jake and his head (LeLutka Quinn)
-
Apologies, I misread what you said. It is indeed true that if all criteria are met, that it is possible for the sun to be at a 90 degree (or extremely close to it) elevation. However, the criteria are extremely specific and fall outside what most people would expect. For example: as you highlighted, the time of midday may not equate to the exact midday point of a given point on the Earth due to the use of timezones. I'd argue, however that most people would think of midday as the time of midday, rather than the solar midday. I'd also argue that the majority of people wouldn't assume that the midday preset was deliberately made to represent a point on the equator on the day of the spring / autumn equinox. The San Francisco example shows what someone from North America might expect to see at midday.
-
Not quite. For example, the meteorological data for San Francisco on the Spring Equinox 2023 at midday places the sun distinctly not at a 90 degree elevation. https://www.suncalc.org/#/37.7771,-122.4197,12/2023.03.20/12:00/1/3 This is closer to being true, although, again, not quite 90 degrees. Today's date, for example: https://www.suncalc.org/#/-0.0201,109.337,14/2024.03.01/12:00/1/3
-
It is actually relevant as the midday preset was updated in the PBR viewer, and this complaint is one which was addressed. The new default midday no longer places the sun directly overhead (because, that doesn't really happen in the real world anyway).
-
This is actually coming as part of the glTF stage 2 (mesh and scene import) project. Lights will be able to be defined in physical units, as opposed to the arbitrary 0-1 scale that is currently used.
-
That issue in particular is likely down to the user's preferences, namely shadows being disabled. Switching EEPs is a hack around the issue, as Nam's (the EEP mentioned as the "fix") uses a high level of ambient light to eliminate areas which would otherwise be shaded - not really a PBR issue per-se. (You could reproduce this on the 6.x viewer)
-
If the clothing creator packages a specific EEP that they require you to use in order for the clothing to display correctly, that's a sign of faulty content. PBR enabled clothing does not and should not require the use of a specific EEP preset.
-
Yes. An avatar stood within a reflection probe will have it's reflections and lighting influenced by it. Reflection probes always work based on the EEP currently applied in the user's viewer, so any manually applied EEP will display the correct lighting within that probe for that setting, combined with any local lights (if any are present).
-
This intentionally doesn't work, so that's a non-issue. https://wiki.secondlife.com/wiki/PBR_Materials#Unsupported_use-cases
-
PBR LSL funtionality is lacking existing legacy material features
Jenna Huntsman replied to Kplh's topic in LSL Scripting
Yes, this is how this works. The stated reason for things working this way is because the region (where the script is executed) doesn't actually know anything about the contents of a material asset, but does know the overrides (this is because the overrides are stored locally on the region, whereas content in the material asset is on the CDN, which the region doesn't communicate with if it can be avoided). -
This is incorrect- reflection probes are pretty much standard practice in other engines. See: Unreal Engine 5.0 - https://docs.unrealengine.com/5.0/en-US/reflections-captures-in-unreal-engine/ Godot 4 - https://docs.godotengine.org/en/stable/tutorials/3d/global_illumination/reflection_probes.html Anyway, it is indeed a bug that Planar alignment doesn't work for PBR materials.
-
Light Bleed Inside Reflection Probe
Jenna Huntsman replied to Porky Gorky's topic in Building and Texturing Forum
This is incorrect. The probe type influnces the projection and sampling of the reflection map, but it doesn't change the object that's showing the refleciton. So if you're viewing the reflection on a chrome ball, then the box and sphere probe types will look very similar. But on a planar (i.e. flat) chrome surface (a "mirror" of sorts) you can easily see the difference in projection types. .. No - probe in each room is how you're meant to be doing it, as you'll then get correct reflections and lighting on objects in each room. This becomes especially apparent when viewed in a nighttime setting where lighting has a much more obvious effect. Generally for interior scenes, unless you've got a massive room, you'll want to use a single box probe for the room. -
Not quite - I did try this at first, but because the object could be anywhere on screen, if it's at the edge of the screen it looks skewed due to perspective, so I implemented the above function to have the object always orient itself to look into the "lens", which resolves the skew issue.