03-28-2011 05:10 AM
Not sure if this is the right place to address this issue but for me its about building in SL so will post it here,
Year and so ago i was pretty upset with the fact that no matter with what tool and how hard u try to accomplish alignment of two prims to be perfectly seamless there is always an angle or camera movement when those ugly flickering seams are visible.........and yes......i did use math,i did use copy function in the editor, i did use PrimDocker, Skidz Prims and few other available tools for precise alignment, i developed my own textures for masking the flickering lines, i tried to build in the way that i can hide and avoid such and even when my Sl runs on full performance and my AA is set on x4 i still see "them"
My obssesion didn't go away even after few months pausing the SL ....and now when back and want to build again..still here they are.......flickering galore all over the place......I know that some , if not most of u, will suggest to go over it and accept the limitations of Second Life and so but after i tried Phoenix viewer and discovered that it has one digit more in editing window for movement on XYZ as oppose to Viewer 2 i got very interested in the fact that it might be possible to have even more digits available also in Viewer 2 or soem viewer i am not aware of.........
So, my question is:
is it possible in any way to, by some setting or "hack" , raise and have 7or even 9 digits in the editor and what viewer is offering the most of digits available and as such is best for building?
I made recent reserach on SL market place to check if there is some new alignment tool but besides those "old" ones, that dont work reliable at all anymore, wasn't able to find a single new and advanced one.
03-28-2011 06:02 AM - edited 03-28-2011 06:05 AM
As far as I know, that flickering only happens when surfaces overlap. It will happen even if they are perfectly aligned*. You have to do your construction in such a way that you don't have any overlapping surfaces. In some cases, where one surface is entirely within the other, such as the edges of walls sharing a corner, it can be solved by making the smaller surface invisible (texture "default transparent"). It's hard to say any more without seeing the offending constructions.
* Because it's due to the rounding effects in the graphics processor arithmetic, I think (but stand to be corrected).
03-28-2011 06:06 AM - edited 03-28-2011 06:10 AM
a few viewers off extended precision in the build edit tools, but there is ever chance that you will be disappointed....
the problem isn't just the precision of the build tools... it's the the precision of the textures.... even with perfectly aligned edges, there are still edges, and the video card tries to render them (yes even with AA set up to 16x).
there are tricks to help control it, such as making hidden faces invisible, using full bright to prevent shadowing issues for certain sides, using planar mapping and alignment tools found in TPVs, etc. but even then if you get up nice and close, there ar going to be seams some times at some angles at some distances.
learn to love the reference ruler mode... way better than prim docker.
build at ground level... if you are high enough, you lose some available precision in position.
eliminate or color match interior texture faces... then if they show through they don't interfere
Use a TPV that offers extended build tools like extra precision, the "align" tool, and auto alignment of planar textures
I believe you can set the number of digits of precision that will show in phoenix, and in cool.... 7 is the maximum effective for any float control, but it will *try* to set more if you type them in (up to the limit of floating point capacity)
03-28-2011 07:27 AM
Even though there are 2 ot 3 decimal places in the edit window I type in 4 or 5 to align prims and it works accordingly. I expect that the number of places that can be used are far more than what are shown but I'm not sure how many. I'm very concerned how my builds line up as I expect you are. 4 places is enough for most things but I have used 5 places on occasion when working with prims joined at an angle especially. Hope this helps.
03-28-2011 08:55 AM - edited 03-28-2011 10:35 AM
As Mot said, you can type way more than just 3 decimals into the standard viewer, and the numbers WILL take. The display will be rounded off to three decimals, but the actual positioning of the prim will honor whatever you've typed (up to six decimals if I'm not mistaken).
Also, the scripted tools you mentioned use a whole lot more than just three decimals (again, I think the cap is six), as do the on-screen rulers. And by the way, if you haven't been using the on-screen rulers for alignment, you absolutely should. They're WAY faster and more convenient than any of those scripted tools.
However, even with all of the above being the case, understand that the graphical anomalies you're seeing may very well have nothing to do with the absolute size and position of the prim objects. If the system were capable of allowing it, and if you could type fast enough to make it feasible, you could enter in a million decimal places, for what would be precision down to the micron in RL, and you'd still see those gaps flicker in and out of existence on-screen, as you move the camera around. The issue has far more to do with how real pixels are drawn by your graphics card and monitor than with the precision at wich imaginary objects are placed in an imaginary world by imaginary measurement units.
If you've got a good system, with components well designed for realtime 3D graphics, and you've got it set well (anti-aliasing to blur object edges, anisotropic filtering to keep textures in proper focus over all viewing angles, high quality poly counts, etc.), then the artifacts will be kept to a minimum. If you've got a lesser system, and/or you're using lesser settings, then they'll become more exaggerated.
Remember, we're not talking about RL physics here. Solutions that would be perfectly intuitive and natural to figure out in RL do not always apply. In RL, what we see is in perfect harmony with how things actually are (assuming you've got clear eyesight, of course). But in a 3D simulation in a computer, that's not the case at all. The visual and the physical are entirely separate things, governed by entirely separate rules. What you're seeing on the screen is never anything more than the computer's approximation of what it thinks it should be showing you, based on the information available to it at the time, for each frame.
On-screen display is largely about angular mathematics. If a surface is X meters wide, and the camera is looking at it from a Y-degree angle, how many pixels will it take to draw that surface? If another object that happens to be parked next to it is the same size, and it's being viewed from exact same same angle, how many pixels will be needed to draw that one? The number can't be the same for both surfaces, because of foreshortening, the natural consequence of displaying 3-dimensional image on a 2-dimensional screen. So, after the right amount of pixels has been figured out for the drawing of each surface, the next question is which particular pixels on the screen will be used for each of the two objects? Put all that together, and you just MIGHT get the two objects appearing to seamlessly butt up against each other.
...or you might not. And here's (an oversimplified explanation of) why. That question of how many pixels are required to display the surface is almost never going to be answerable as a whole number. Just about every time you do the math, you're going to end up with some fraction of a pixel as a remainder. Since there's no such thing as a fraction of a pixel on a screen, the results of course need to be rounded to whole pixels. If each of the numbers is rounded up, then you get a one-pixel overlap. If they're each rounded down, then you get an empty pixel in between the two surfaces. If it's one up, one down, then there's no seam at all. Factor in the calculations are redone for each frame, and there's your flickering seam right there.
Anti-aliasing, in theory, will blur over the overlap/empty pixel, and the seam will disappear. But as we all know, theory and practice aren't always the same thing. If your computer isn't good at AA, or if the calculations are such that it doesn't think a particular pixel needs to be blurred over, or if it's not being blurred quite enough, then all bets are off.
Even ultra high end non-realtime 3D simulations, like big budget Hollywood animated movies, end up with per-frame artifacts. It's not unusual for artists to have to go in in post to clean things up.
And all of that's before you take prim drift into account, which happens all the time in SL.
I'd strongly encourage you to let this obsession go. There's no way to ever fully overcome the problem.
- The Doctor
03-28-2011 10:04 AM - edited 03-28-2011 10:10 AM
i expected some of the comments and they are perfectly ok, thank you very much for them but before i find "my way" of dealing with the problem i wanted to see if there is anything, not just only a tool but skill or knowledge that i can learn and incorporate in my building process.
I can live with this issue as long i have the feeling that i did all that is to have it right.....those "objective" aspects and reasons why still, after i done max to avoid them, can see flickering and dotted lines are then sort of Gods will effect and will accept them as such.
Real news for me is possibility to type in more then 3 last decimals in Viewer 2.........never tried that and can't wait to do so
As for the TPV...any suggestions beside Phoenix, building wise?.........
03-28-2011 10:39 AM
I get what you mean about being able to live with it, as long as you know you've done everything you can. That's the right attitude to have, as far as I'm concerned. The only potential problem there is just in determining at what point to you declare that you really and truly have done everything possible. So, I'd just caution against getting too wrapped up in questioning yourself, if that makes sense.
As for TPV's, I have no idea. I've never used one. I'm just too paranoid about my login info, I guess.
- The Doctor
03-28-2011 02:08 PM
In one of my Linden Homes I noticed that prims do not stop light, even after completely lining a room with black flat prims the place still lit up from the neighbor's disco-tech. As light passes right through prims I believe it illuminates all surfaces including were two prims are butted together causing an annoying glittering, often I've been able to get rid of the glitering by turning the butted together surfaces 100% transparent.
Another possibility is prim creep due to server round off error. A simple build looked perfect till I tried turning the whole thing 45 degrees then I saw all sorts of gaps open up between prims, small gaps but enough to cause the annoying flittering at the seems. There's probably a whole bunch of interactions between size, position, rotation, and other parameters that can make number of digits blow up, see what you get when you divide 6 by 7.
03-28-2011 03:18 PM
Knutz Scorpio wrote:
I noticed that prims do not stop light
Correct. Prims do not block light at all. In fact, nothing at all blocks light, under SL's current lighting model, which is why no objects in the world, be they prims, avatars, trees, whatever, cast shadows of any sort. All the graphics engine knows is that if a surface is facing a light source, it should be more brightly lit than if it's not. The question of whether or not there might be another surface in the way is never taken into account at all.
Even the foot shadows that show when your avatar is standing on the ground aren't really shadows, by the way. They're just a couple of small polygonal planes attached to the avatar mesh, which show a translucent black foot-shaped silhouette texture when you're standing, and show a completely transparent texture when you're flying.
A MUCH better lighting model is in the works, though. It's still experimental, but if you've got a good enough computer, you can use it now. Here's how:
1. Make sure the Advanced menu and the Develop menu are visible in your viewer. Press ctrl-alt-d to show the Advanced menu, and then ctrl-alt-q to show the Develop menu.
2. Click Advanced -> Show Debug Settings
3. In the Debug Settings dialog, select renderDeferred from the dropdown menu (or just type it in), and set it to true.
4. Now, click Develop -> Rendering, and enable the various options under Lighting and Shadows. The first option will allow objects to cast shadows from sunlight, moonlight, and local light sources. The second one enables screenspace ambient occlusion, and allows for smoother shadows. The third turns on global illumination.
If your computer can handle all that, it looks quite nice. If it can't, then either your frame rate will drop to single digits, or you'll crash, or you just won't be able to enable those features at all.
Even with all of these features enabled, though, you still can't block out all light entirely. Only direct light sources cast shadows. Ambient light still permeates.
Anyway, none of that has anything to do with what we've been talking about here. Even with shadows enabled, you'll still see all the same seams between prims that you were seeing before. Depending on the specific lighting conditions, a particular seam might happen to shadowed instead of lit, but it's still there, and just as visible, either way.
In fact, sometimes having shadows enabled will make the seams even more glaring. Light can bleed through the cracks to slice right through the shadows, drawing yet further attention to the fact that an object made of prims is not in fact a single contiguous surface.
This is just the nature of what happens when you butt two surfaces up against each other in a 3D simulation. There WILL be a seam there, no matter what, and very often, that seam will be visible.
When mesh goes main, we'll have a lot more options at our disposal to eliminate and/or hide seams. An entire house could be a single seamless mesh, for example, instead of a collection of individual building blocks. Or two adjacent mesh objects could be beveled in such a way that their corners could intersect in a manner that appears to be seamless. There are lots of possibilities for these things with arbitrary meshes.
But until then, SL remains a blocky prim world, and seams are just inherent to that condition.
- The Doctor
03-28-2011 06:11 PM
SHTAX Waffle wrote:
[...] As for the TPV...any suggestions beside Phoenix, building wise?.........
Cool VL (not in the TPV list, but legit and can be found via google) has extended build tools, and is often one of the first to backport new features from V2. Imprudence and Ascent also focus on content creation tools.... Firestorm and Singularity aren't very feature stable at the moment, and Kisten's focuses on eye candy like shadows and filming.