Jump to content

polysail

Resident
  • Content Count

    246
  • Joined

  • Last visited

Community Reputation

170 Excellent

About polysail

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Do each of these "Child Users" come with their own camera? Or is all of this data fed into the MVP matrix for the single user camera?
  2. Yes ~ rendering distant elements with a secondary camera with a different Near / FarClip plane a lower FPS is how most games handle composing massive vistas. This helps with rounding errors as well as performance since it eliminates huge ZBuffer distances. The Z-Axis in this case is relative to camera ~ and represents the overall depth of the scene, ~ not to be confused with Z height in the SL World ~ which is how high up things are~ which also causes jitter due to the fact that things are rendered in world-coordinate space ~ these are compounding errors... but yeah... Like I said ~ Massive
  3. Making image planes for entire sims in lieu of actually displaying the content of those sims simply does not work, due to the nature of such planar representations. They don't parallax correctly ~ meaning if you had such a thing while ~ say riding a motor vehicle across the mainland ~ the trees and houses up until the image plane would move correctly ~ then the trees on the image plane would not. They also don't do vertical changes correctly ~ so if there is any Z height difference, due to terrain ~ or say from a flying vehicle of some sort ~ or just a flying avatar ~ the illusion
  4. Yes ~ the "make sim surrounds on private islands a standardized feature" idea makes a lot of sense I think ~ it's also the kind of small incremental change LL seems to be comfortable with. Viewing / impostring adjacent sims / mainland sims ~ is a bit less so ~ But as I said in my original reply ~ that's a very different ask from the notion of "Make SL able to do AAA type 'Big Worlds' ~ " which implies a necessary full coordinate-space rework.
  5. Uhm~ I'm not sure how to reply to this ~ you tell me I'm incorrect ~ then proceed to explain ~ rather precisely ~ exactly how I'm correct? Maybe my explanation wasn't clear?? Yes SL has the 'open world' split up into multiple integrated coordinate spaces. That's a sim. When you set foot over a sim crossing you go from +255 in one coordinate space to 0 in the next. But within the bounds of each sim, everything is calculated, in world coordinate space. Every bone movement, every object movement, every ~ everything. You can see the errors of this visibly start to fail by~ as you
  6. There's two very different requests here. 1: "Put junk off-sim to replace the old Sim-Surround Megaprim Hacks" 2: "Have an entire exquisite horizon-line vista that is renderable from any point ( and in the cases of all of these triple A game titles showcased ~ able to be walked to as well ) These are two incredibly different things. One is expanding upon a stop-gap hacky measure to try and have matte paint type stuff exist outside a sim's numerical coordinate system~ the other... well... the other is complicated... SL is rendered in world-space. Every entity in SL
  7. Thank you Beev~ it was a lot of effort ( mostly on Beq's part ) I managed to erroneously (partially?) convince Beq pretty much every step of the code was wrong before we managed to convince ourselves that it actually wasn't. But the change won't be that ground-breaking for SL. The average mesh in SL fits more or less just fine in a cube, or a half-cube-volume. (Think dresses, beds, sofas, small bushes , rocks etc). The object ratio is only 2-5 off of a perfect cube. So the tangents would be off, yes, and look sliiiightly weird, but ~ not really in a manner that would be immediately
  8. No they are not. This is why I explicitly stated that 3ds max is NOT a reliable tool for analyzing this. Objects taken on a tour through SL behave 100% identically to import if they originate in an inverse-normals piece of software such as Maya. I can take my test-shape in Maya, import the "in a Box" version of it and the non-enclosed copy of it into SL, view that the debug normals tool tells me they're totally wrong. IGNORE THAT. Export them~ Re-import them into Maya and compare all my vertex normals, and not a single one will be deformed. This in combination with the code exploration of
  9. Yeah. I've been down that entire rabbit hole, and came out the other side. ( I think ) .... Remember my very first going in position on this was "Scale Matrices Suck, I routinely get them wrong." So my confidence level in all of this has been fluctuating wildly between "pretty high ~ but not certain" all the way down to "I have no idea what I'm doing". Maya handles vertex normals with inverse object scale. This is NOT how 3ds max handles it ( As best I can tell ) However, the only way to get 3DS max to render vertex normals is to use the old Editable Mesh asset type, instead of E
  10. The scale multiplier in the 3rd tab is a universal omnidirectional scale value ( applies to all axis equally ~ X Y Z ) so it doesn't actually affect the normals data at all, also you can't zero it out ~ so there's no concern for 0 magnitude normals.
  11. @ZedConroy Thank you for puzzling through the first part of this. This is has been driving me bonkers for the better part of half of a decade. https://jira.secondlife.com/browse/BUG-228952
  12. Okay ~ I've done some preliminary testing. Nothing 100% conclusive yet ~ but by all indications ( at least for meshes originating in Autodesk Softwares )~ for any meshes that aren't perfect cubes ~ during the quantization process ~ it seems to be re-calculating the normals for them using an inverse scale matrix for the surface normals ~ instead of a scale matrix~ meaning ~ the thinner and flatter your object is ~ the vertex normals of the object are going to be distorted ~ by not only the ratio of the difference from the mesh to a standard cube ~ but then that ratio AGAIN beyond that ~~ m
  13. Actually, once I hit post ~ I remembered. I'm pretty sure just exporting a mesh into a DAE file format "explicitly defines" it's vertex normals. DAE is a simple format, and does not allow for edge smoothing. ( Again I haven't tested, but I have a fuzzy recollection here ) that if I export a mesh with 'regular' handling of vertex normals from either 3ds max or Maya~ that just immediately re-importing it will require them to be "unlocked" again. it's just a limitation of the DAE format.
  14. Beq is 100% correct ~ all meshes are stored internally in a 'cube-like' form ~ where the mesh is scaled to fill the volume of a unit cube. How this affects things~ and whether that's "expected behavior", that's ..... that's another question~ After reading this entire thread a couple times ~ I'm thinking this is actually a long buried bug. I haven't tested this personally yet, but after reading everything here and seeing the examples, SL should be capable of preserving the correct vertex normal directions while doing whatever scaling operation it needs to during the quantization proces
  15. Correct me if I'm wrong here ~ but ... uh... don't vertex normals HAVE to be recalculated under deformation? Constantly? That's a substantial part of what a GPU does. ~ That's it's 'thing' ~ otherwise nothing would animate ~ period. No? I think? If I had to take a wild-flying guess as to what's happening here ~ is somehow slider deformation isn't getting fed to the lighting calc ~ Somehow? I'm no rendering expert either ~ but this is definitely worth investigating further.
×
×
  • Create New...