The sky isnt being rendered well in preview mode

[Cyber-Angel]

I think it would be case dependent, but as a general rule the foreground and sky should be visible (By Default) to see the sky for the point of view of clouds, sun position and its interaction with the terrain, and the terrain (Foreground included) for seeing surfacing, displacement and the like. I can envisage times where you might want  to considerate on the terrain or the sky separately (To allow refinement of problem areas, or for certain production needs) the ability to focus on these areas (Via clipping planes or other methods) should given a properly designed renderer to free up system resources and considerate on those areas, weather this is in the 3d Preview or  on the image at render-time, its about allowing flexibility of work-flow to meet the needs of the artist.

Regards to you.

Cyber-Angel               

[Matt]

Yes, of course. It should always try to show *both* in the default view. That is why we are having this discussion - the problem is that it is difficult to show both.

Matt

[Cyber-Angel]

This to me sounds like an incremental problem that will take time to solve but I really don't think it is so insurmountable as to be impossible, what in your view are the areas of difficulty has you see them so that I may better understand the issue/s from a developmental perspective?

I have not encountered this problem with clipping planes before in what I have read on them, it would be interesting to do some research and find out weather other software during its development encountered such problems and how they where fixed (If such data is in the public domain), but I would not know the search criteria for such an enterprise has I have stated in other posts I am not a programmer and do not calm to be one.

As Sherlock Holmes said "Once you have eliminated the improbable, what ever remains how ever unlikely must be the truth"   

One question comes to mind is the implementation of Open-GL used for the display of the 3d Preview Pixel Accurate and if not would making it as such help deal with the Clipping Plane rendering issue (Providing this is feasible)?

Regards to you.

Cyber-Angel       

[rcallicotte]

I'm a lot more interested in the basic functionality being accomplished by year's end (or thereabout) rather than nitpicking about the preview mode.

[Oshyan]

Most other software doesn't run into this because it doesn't deal with the huge ranges of scale that TG2 does. The background sphere that the sky renders against is large enough to encompass the default planet by a good margin, and the default planet is Earth-sized, so you can imagine it's pretty large and far away in terms of meters. TG2 has accuracy down to millimiters I believe, and I'm not sure if it scales that with distance, so depicting things on large scale with that kind of accuracy can be out of the range of capability of some graphics cards and/or drivers. The simple fact is many other graphics applications just don't require depicting that wide a range of scale and hence the accuracy of the depth buffer doesn't necessarily have to be as high. As graphics cards evolve more and more emphasis is being placed on precision and accuracy as well as rendering large ranges of scale, so this problem will be increasingly rare I think. Already it occurs on a minority of systems, so I don't really think it's worth spending time creating special case functionality to address given the small group of affected users and the existence of an effective workaround. It should be documented as a known problem with some configurations and a solution provided and then left at that.

- Oshyan

[Cyber-Angel]

I just did some looking into depth buffers, could it be that what is going on with the far clipping plane is an example of Z Fighting and I came across the Wikipedia article http://en.wikipedia.org/wiki/Z-fighting on the subject and it mentions several workarounds to try and resolve the problem, these are:

Higher resolution depth buffer by using a W-Buffer:

Using a Stencil Buffer:

Post transformation screen space Z-buffer offset:

And Invariant Vertex Transformation.

Like I said these things take time to resolve and solutions to them found and implemented, only trying to help. 

Regards to you.

Cyber-Angel

End of Line.   


   

[Oshyan]

The simple root of the problem is that not all graphics cards have the same fundamental capabilities. Some have less accurate z-buffers, some don't have w-buffer support at all, etc. No matter what solution we used, as long as we're relying on graphics card hardware to implement it we'll be limited by what's available on the user's system. If we don't use graphics card hardware then we rely on software, which would probably be a lot slower and not supported on all systems (e.g. Windows Vista).

This is really no different than what games have to deal with, although it's far simpler, and although there is always someone complaining that the latest game (say Crysis) doesn't work on their 5 year old system, there is really just no way to support everything fully without glitches. I think you'll find that other similar 3D applications that use graphics card display functions for viewport rendering (read: the vast majority of them) have similar or often much worse problems with less-than-outstanding graphics cards. In fact many of the higher-end graphics programs like 3DS Max and Maya have specific lists of cards that are supported and they often recommend purchasing special graphics cards that can be $1000 or more for best performance and viewport accuracy. I think TG2's problems in viewport rendering are fairly minor by comparison.

- Oshyan

[Cyber-Angel]

Such is life what is needed is standard for graphics cards (Not likely any time soon) for feature set commonality among cards, what software would do in a ideal world is automatically look for and use features if present (Some software looks automatically for and uses Transform & Lighting if present, by way of example). How ever such universality is not on any ones horizon soon.

All the best with what ever solution (Even if not perfect) can be found to this small problem, what fun community based software development is! I also think that this conversation can go no further at this juncture unless further useful data can be provided; it has severed its purpose of providing a sounding board for idea's weather they prove useful or no is not for any one to rightly say at this time, a case of Que Sera, Sera I would say.     

Regards to you.

Cyber-Angel

End of Line