Helena Mitasova - staff
helena at gis.uiuc.edu
Tue Jan 23 11:08:44 EST 2001
>just curious: How did you/Bill generate these nice images? Which
>projection did you use?
1.the globe is done from latlong data in SG3d, you can have 3D terrain, color
and vectors draped on it. It was done by Bill. I am not sure whether
this is available in NVIZ (I don't have latlong data to try it,
if it is not supported it should be added to my list of things
which were in SG3d and are not in NVIZ.)
2. I believe that the -q problem with NVIZ was fixed so you can remove it
from my list.
3. Also, do you have the GL version of nviz (it should be nviz2.1, I believe)?
It may be useful to make it available for developers so that the Open GL
and GL handling of lights/normals could be compared. That version should
also draw a flowline when you click on a surface with "What is here" option
(instead of drawing a line from the previous point) If you don't have
it I will find it on GMSL machines and put it on our webserver for you
(sorry if I am asking the same question that I asked already)
the examples with NVIZ lights are at
>I'm not sure if I replicated "the bug" or not. After loading in a large surface
>(2300x2500) I increased the z
>exaggeration to about 35 and most of the map was dark. It appeared to be
>only a small portion of pixels were being rendered with bright colors
yes that is it, although I did not play around with the Follow ViewPoint,
but I believe that all the following problems are related to light,computation
of normals and/or angle between the line of sight from the viewer
and a surface normal and/or some initial settings/hard coded constants, related to
a) light not working when the surface values are decimals between 0.- 1.0
b) parts of the surface not being rendered for certain combination of viewing
position, exagerration, size of the raster, etc... (see the example images above,
it seems that it "thinks" that some parts of the surface are hidden, so
it does not render them, while they are actually visible)
c) light is more difficult to use in NVIZ than it was in SG3d, in spite
of the same concept - it may actually be useful to look into SG3d to
see how the light is set-up there and compare it to NVIZ.
>One thing I noticed is that we may want to change the lighting controls,
>they do not seem very intuitive to me, but that's just my opinion.
You are right that the lights are not too easy to use in NVIZ, but I
don't think that it is in the type of controls, although they could
be enhanced too, e.g. by adding N,E,W,S etc.,
The real problem is in settings.
When you start SG3d the light is about right and it is higher than in NVIZ.
All what I usually did was moving the dot in the viewing angle square around
its perimeter to get it lighted from different sides. Almost never had I
gone with the dot to the center, unless I needed some special effect.
In NVIZ, the light starts too low and the lighting which you get when moving
the dot around the perimeter is inadequate. You have to move the dot
close to the center to get suitable light and work around there - this is
indeed very un-intuitive. Also the height of the light source is set too low
and even on maximum it never gets to the height as it was in SG3d.
It would be useful to see what were the defaults, initial settings and
scaling of light parameters in SG3d and see whether it would be possible
to fix this in NVIZ - it may make NVIZ much more pleasant to use.
>it seems that interrupting the render process is not truly interruptive.
>While playing around with the lighting I interrupted the render many
>times, yet when I stopped and let the render finish it flashed between
>wire frame and rendered surface several times. This seems to indicate
>that the commands were being queued somehow.
that may be true, although I am not sure whether this was addressed by Bob
Covill's changes or not.
As this email is getting too long I put a compilation of email exchanges
that we had about the normals at
Bill was supposed to look at these issues weeks ago but haven't
heard from him for quite a while.
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'
More information about the grass-dev