Jump to content

polysail

Resident
  • Posts

    248
  • Joined

  • Last visited

Everything posted by polysail

  1. Aww... Now what am I going to do with my Wednesday mornings?
  2. I'm using gmail and as of a day ago it was working just fine. So I don't think it's a gmail problem.
  3. 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?
  4. 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 changes to SL render code would be required ~ but technically all of this "is possible". The question is (as with all possible things ) "would it actually materially improve anything?" I don't know the answer to that. SL is a very specific use case ~ and as animats has pointed out ~ it's not clear that rounding errors at these "relatively short "1-3 km viewing distances would be material enough to cause notable jitter. I don't actually know. I'm not a graphics programmer ~ I just play one on TV.
  5. 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 would break. The thing is ~ the people who actually do want their draw distances turned up to 500+ meters ~ are all the members of the SL community who are very interested in boating ~ flying aircraft ~ etc. You can't simply doodle their runway that's next to a mountain on an image plane and expect them to be happy about it ~ these people care about realism and accuracy to the degree that they want to make sure the landing lights on their run way pulse at the correct number of flashes per minute to mimic their real-life counterparts. They don't do lighting correctly. If I place a house on a hill on a horizon line while the sun is setting it reflects light properly in a manner that tells someone ~ even a kilometer away "there's a box there with a roof shape on it" if you replace that with an image of a house at some given time of day ~ it will necessarily look incorrect and pretty much every other time of day. Even if you try and mitigate this issue with ~ say having four different image sets ~ This still won't account for the differentiation in environment settings. Just using library EEP settings "[NB] P-Haze" vs "Dynamic Richness" will yield totally different sun angles and color tones at the same "time of day" You simply cannot use baked lighting in a dynamically lit environment. It just doesn't work. It's for the above reasons I didn't really take the "let's image plane an entire sim" idea seriously ~ among the myriad of other ( sort of proposed ?? ) notions ~ and instead focused on other steps to improve rendering efficiency / calculation spaces in order to improve the SL user experience. Image plane impostors don't work for anything besides foliage and other similarly constructed organic creations that have a central core with branched out components ~ the moment you try to simulate anything with a vaguely solid form ~ the impostor breaks down catastrophically. There is a reason these are not used in modern day game engines. Image planes won't keep SL relevant into the 2020's any more than having pose-ball based animations will.
  6. 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.
  7. 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 indicated flying to 2000 meters and watching your eyeballs shake in your head due to floating point precision errors. This is ~ in stark contrast to how most modern games handle this problem ~ by calculating the world, relative to the player, meaning that there is never anything suffering from precision errors, unless it's in the distance~ which is precisely the paradigm change that I was referring to.
  8. 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 ~including ones that you'd think had a local transform ~ such as a rigged avatar ~ simply doesn't have a local coordinate space. So ~ when you're swinging your arm on your avatar while SL is aware of the skeletal hierarchy in principal ~ as far as the the sim code and renderer are concerned ~ SL is going "move bone mElbow at sim location 140.444 , 22.634992 , 44.9294" to denote the location that your elbow is moving at in world-coordinate space. Because of the lack of coordinate spaces~ SL simply can't do the AAA game "walk into the distance" ~ "look at all the pretty houses on the horizon line" the underpinning maths simply aren't there. Floating point numbers only have so many degrees of precision. In order to fix this ~ we'd literally have to re-invent the entirety of the SL coordinate space, to include object-space and update the render code. At that point ~ we might as well just re-invent the rest of SL as well. Which I'm not against in principal ~ but essentially to 'properly address this' ~ you'd literally have to make SL 2.0 (Not Sansar). As for ~ "Seeing neighboring estates" ~ I'm a bit confused about this ask. They're private estates, that was the entire marketing point of them ~ that you don't see the adjacent sims, that's what makes them "Not the Main-Land". Or are you proposing that ~ each region come with an extra surrounding 8 regions of 'make it pretty space" ?
  9. 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 noticeable. That being said ~ I am immensely pleased it wasn't just 'in my head' that something has been 'off' all these years ~ As I said in my first ( very incorrect ) JIRA report ~ I've been chasing this bug, in some form or another ~ for the last 5 years ~ so, it's a personal victory for me, and it will help make people's lives in SL just a little bit better ~ which is nice! So thank you again @ZedConroy for giving me the point in the correct direction that I needed. I was very much "interested". One last thing: Scale Matrices Suck. I routinely get them wrong...Thankfully Beq doesn't. 😆
  10. 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 SL's vertex normal code ~ turning up nothing but inverse_scale calcs leads me to believe that SL is handling normals correctly for most cases, but simply is displaying in the debug tool that it's doing it incorrectly. Which is ... all kinds of confusing. However ~ We're not out of the woods yet ~ so to speak~ ~ If I do this same experiment in 3ds max, MANY things can change this. If I have a scale applied to my object in 3DS max at a transform ( object ) level, 3ds max will handle this with it's bizarre normals * object scale matrix calc... and as best I can tell, export those.... which will require a similar parity normals * object scale matrix inside SL to get them back into parity with the system. ( Which is what Beq's optional patch addresses. in addition to adjusting how normal maps are rendered ~ but it's not a true fix.) However, if you Apply XForm in 3ds max prior to export, you will note that the moment you do this, 3ds max recalculates all the vertex normals with normals * inverse object scale, bringing it into parity with SL and Maya. However~ If you started off with a 14.0 , 1.0 , 1.0 sized object, that has ( 1.0, 1.0, 1.0 ) scale ( XForm Applied in 3ds max ) ~ and then take this ( 1.0,1.0,1.0 ) scale object and import into SL~ SL will compress it into an internal unit cube .SLM File which is akin to taking your mesh object in any 3D application, scaling it down to fit into a ( 1.0,1.0,1.0 ) sized cube and APPLYING THAT TRANSFORM, making the object effectively 1.0 sized cube, with ( 1.0,1.0,1.0 ) scale, then scaling it back up to object size, at the transform ( object ) level. In the case of our 14 meter tall box ~ regardless of what software it was sourced from is now a ( 1.0,1.0,1.0 ) sized Object with a ( 14.0 , 1.0 , 1.0 ) scale. Which if you import it into 3ds max, we're back to an object with unapplied XForm data which uses normals * object scale to draw its normals in 3ds max, and they LOOK WRONG until you apply XForm ~ returning the object to it's original 14.0 , 1.0 , 1.0 size ~ with a unit identity transform. That does not mean this is how it's handled in SL. ( Despite it being how the Render Debug Normals indicate that it is being handled in SL ... it's... there's many steps to this ) On top of this ~ absolutely NONE of the above addresses the original concern that normal maps ( note: Not vertex normals themselves ~ ) in SL are displayed in a manner that is completely consistent with how the debug tool ( apparently incorrectly ) draws the vertex normals. This bug is weird. VERY weird. Also it has nothing to do with the handed-ness RGB channels of normal maps~ the incorrect display of an arbitrary planar normal map displays incorrectly on the side of a flat cylinder in SL. That's not a problem with the normal map, it was baked in planar space with all the correct color channels and magnitudes, but when you stick it on a cylinder squashed flat, it makes the side of the cylinder render as if it has it's vertex normals ( nothing to actually do with how the normal map was created ) squashed to match the bounding box, just like the renderdebug normals in SL seem to indicate they do ( wrongly ) and in parity with how 3ds max handles un-applied object transforms. This is directly contrary to all the other inverse_scale normal calcs both in mesh packing and unpacking. If you doubt me, try doing the same test as I did ~ ignore debug normals, turn off all atmospheric shaders and just look at how objects reflect light. They do so in a manner consistent with having their vertex normals handled correctly ( in an inverse_scale manner ).
  11. 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 Editable Poly. So, I'm really not entirely sure how the software handles this internally. 3DS max has a lot of bizarre intricacies behind the scenes, this might just be 'one of those things' it does the '3dsmax way'. Which can be kinda "speshul" sometimes~ That being said : We've found code in SL now for object storage ( squishification ) and subsequent expansion ~ for object rendering. Both of which take the normals and multiply them * inverse scale. As long as these two operations use the same maths, then ( in theory ) everything regarding mesh storage and recall is actually fine. Conversely, if both calculations used object scale ( like 3ds max appears to ) it would also be "okay", however rendering scaled objects would have to be handled in a vastly different manner~ like I assume it is handled in 3ds max. But this is not presently the case inside SL. SL clearly has the maths to use inverse_scale for both calculations. However, the display of vertex normals in SL, using the debug tool ( the little blue lines we look at ) clearly uses object scale, not inverse scale. What this means... I honestly have no idea what is going on at this point. If I turn off all atmospheric shaders, and disregard rendered debug-normals, and just analyze this with an Ambient Dark environment and a single point light SL seems to render surface normals correctly. But I can't be 100% certain that this is the case, because again, normal maps and shaders are clearly still borked. The only two things thing I am 100% certain of is that : 1: Inside SL, the display of a normal map on a curved object scaled flat is incorrect. WHY this is the case, is not something I understand yet. Still digging on that one. 2: The display of vertex normals (rendering of debug type info ..aka drawing little lines out of the verticies ) , both in 3ds max and in Second Life both, is unreliable, and should not be used as a deterministic tool to decide what is going on~ even though I used it as such in my JIRA, I realize now that may have been in error.
  12. 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.
  13. @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
  14. 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 ~~ meaning if your initial object measures 0.25m x 1m x 1m ~ the surface normals are being calculated in a manner which ~ in order to get them to match the original shape ~ your object must be scaled to 4.0m x 1m x 1m ~ 16 times the original mesh dimension in the axis that was "off". If my testing is correct ~ and this is the mistake...... Holy @#*%*@
  15. 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.
  16. 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 process ( where it converts the DAE into an internal 'second life mesh'). This looks like pretty definitive evidence that it does, in fact, NOT do that. Scale matrices suck. I routinely get them wrong. My guess is that the mesh uploader is also handling this incorrectly. Perhaps it's just usually not that noticeable~ but it gets progressively worse the more of a deviation that your object has off of a cubic shape? ( Though that last sentence is making me ponder ~ how does it handle flat planar objects? Are they special cases? ) I'm not really sure. SL does take in original object vertex normals and apply them to the uploaded mesh, it doesn't simply recalculate them all from nothing. At least I've seen it do that in cases where the vertex normals are "explicitly defined". To define what I mean by "explicitly defined" means ~ it's the case that Optimo referred to in his post where if you're in your 3DSoftware attempting to edit your normals with the usual face/edge tools that set up hard/ soft transitions have seemingly no effect on the object until you "unlock" them. I'm not sure of the precise mechanics of the how and why of this situation across all thee different programs discussed in this thread, but I know SL does acknowledge them as inputs. How those inputs are handled ~ and whether they are handled correctly. Well that's a question worth asking. It shouldn't matter what the source application is, 3ds max solves vertex normals mostly behind the scenes, much like Maya does, unless it gets a asked to import a file with "explicit defined" vertex normals ~ if my memory serves me correctly... this is identical to how Maya handles it ( I'm not 100% sure on this )? However this behavior noted here ~ regardless of the source application, explains a substantial amount of frustration I've had with the inconsistencies of how normal maps function inside SL. I've not tried setting cubic bounding boxes for all my meshes to see if it fixes all the normal map issues that I've been struggling with, but that will definitely be something I will try from now on with objects that are not naturally cubic. I wonder how this all calculates with rigged meshes?
  17. 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.
  18. Actually ~ Firestorm outperforms LL viewer ~ by quite a measurable difference. Over the years the FS team has been adding in little optimizations and features that speed things up ~ ( some of which have been re-contributed back to the LL default viewer making the Linden Viewer part 'Firestorm' actually! ), and alleviate pain points such as simplified shadows. The biggest single setting that will make you think that Firestorm is less performant is Firestorm ships with an LOD Default of 2.0 ~ which is substantially higher than the Linden Lab Official default of 1.25 ~ https://gyazo.com/effe406fbf750baa63c6aa451bf85c03 Changing the value of this setting governs when objects disintegrate into unrecognizable triangles just a couple meters away from them. This is a common problem on SL due to content creators cheating the Land Impact equation at the cost of a poorer visual experience for their customers. Anyhow ~ the overall point is ~ the lower you push this setting the better your viewer performs~ giving people a false notion that one viewer is inherently different from the other~ in ways that it is not. Edit : But yeah.. stumbled upon this post 'cause @#)% Subscriber things won't let me unsub and I want to scream.
  19. I know very little about the finer details of international monetary transfers. But at face value~ a more geographically equal way of cashing out sounds amazing. But ~ It's not my area of expertise ~ I'm just a girl with a keyboard and a google search engine. I know some of the underpinning problems ~ like having to deal with compliance for money laundering and ~ anti-fraud measures, but an expert, I am not. JIRA is a great place for suggestions though ~ making them on the forums, in dead threads is definitely not a good way to get them noticed. Always always file a JIRA!
  20. Yep yep ! ~ I know there's better options than online currency converters ~ but I was simply pointing out that Paypal's international conversion fee plan is hardly a "BIG MESS" that warrants LL providing a better alternative to ~ like currency conversion websites actually are ~ https://www.paypal.com/us/webapps/mpp/paypal-fees It's about what you'd expect from any other financial service ~ for that amount of money. It's also neatly laid out and explained ~ hardly a money-swallowing black box. Edit: In fact it actually provides a bit better context to the entire conversation that we've been having on this thread about processing and transaction fees. It's 2.9% + a flat fee to transfer from one currency into another, as per Paypal policy. Making smaller transactions have an effectively much higher fee than larger ones. It makes the 5% LL has opted to go with seem a tad steep initially ~ but it might actually be lower for monthly "pay checks" for the average creator. Of course international people still get doubly hit with the Paypal fees on top of that, which really sucks~ but that's back to geopolitical debate, none of which we can rationally expect LL to compensate for.
  21. 480$ USD converts to 424 Euro . That's called an exchange rate. The euro is more valuable than the dollar. ( at the time of writing this it's presently 1.13 USD to 1 Euro ) Much the same way that 480$ USD converts to 8234 Mexican Pesos, as the Peso is less valuable than the dollar. The fact that you're only getting 413 instead of 424 makes it sound like you have a HUGE GAP-BIG MESS of a 3.5% processing fee. Which I very much doubt that LL would be able to negotiate a better deal on that an international finance exchange like Paypal. Edit: I'm going to just point out~ that if I go to a currency exchange website because I'm traveling and need to have Euros instead of dollars, If I hand them 480 USD ~ they'll give me a whopping 388.80 Euros. What's even better is they justify that by using the most expensive exchange rate that it's been in the last few months ~ claiming it's 7% different than it actually is...
  22. Raise your prices 2.5% then? Your 1600 price point objects won't suddenly stop selling if you raise them to 1640. People aren't going to see the 40L$ and go "oh dear no, I can't afford that"~ the 1600 ~ that I could pay.. the 40L$ ~ can't do that ! Passing the cost on to the consumer isn't ideal. But if you really "can't stay in business" any other way. Then that's the clear answer.
  23. The biggest problem with this current situation is that for most people with fixed income, there's no way for them to take advantage of the discounted rate at the moment because 72$ USD on a 1 month notice is simply an impossibility, so they're going to lose out on that 37$ discount come their next billing cycle. ( That's what they're upset about ) The only reason I was able to so easily pay it is I've been floating an annual premium fee on my account out of sheer paranoia, which wound up being a good forward planning thing. So ~ yes the 'planning' argument holds up... sort of ~ but not really. It's a fact of modern life that people who live very near or below the poverty line actually have a higher cost of living than people who are not. Bank fees due to low balance amounts / overdrafts, loans, loan interest, and surcharges for the smallest of things that others ordinarily expect to get for free are facts of life. I can go on for hours about socioeconomic inequality.... But getting upset at LL for being a part of this ecosystem is a tad irrational I think. Legally SL isn't an essential service, though, as I argued earlier in this thread, to many of the residents I'm sure it very much is one. The thing I have a more difficult time arguing that Premium in SL is so essential to need an extra accommodation, especially with the reversion of the basic group limitations.
  24. If you already had a paid premium plan ~ and you buy more again now, it winds up looking like this : As you can see it moved my billing date forward one year from when it was expected to be due.
  25. I've been rolling my stipend refund + SL income back into my premium for 4 years. When I do get extra money, I've made sure to keep an extra annual billing cycle worth of premium on my account, as I've been deathly afraid of getting locked out since I wouldn't be able to just "pay off my debt" without using L$ to do so. So it's been literally the 12$ / yr annual fee that I've been citing on this thread, and it will remain so until 2021, I never have been on a non-annual premium plan. I may not be the best example due to the fact that my net SL income is positive, but that's how I've always managed this.
×
×
  • Create New...