[GRASS5] Re: nviz testing

GRASS GRASS developer
1

Bob,

thank you for all the nviz updates - I finally got around to test
it all myself and it all looks great and I suggest to include it
into GRASS5.0.2

I did not have a chance to test thoroughly the load/save 3d view option
although it seems to work OK (except for the GUI update) - maybe
somebody who uses 3dview could test it further.
The animations could be tested more too but we will be doing that
within next week or so. The tilt, accelerated rendering and the
setting of center via canvas work great.

I found 2 cases when nviz crashes (all old that have been there
from the very beginning):

1. If the user draws a cutting plane through multiple surfaces
with color from top or bottom surfaces and at least one of the surfaces
has different resolution than the other ones, nviz crahses. This is
already in bug tracker.

2. If the user tries to drape a vector layer that is outside the current
region it gets pretty nasty with tons of messages like this
dv = 38022496.000000, dh = 38022496.000000, dd = nan
stuck on 0
cv = 0, ch = 0, cd = 0
untill it crashes. I will file a bug report, unless somebody has
already tried to fix it (it should just give an error message)

There are 3 other unpleasant behaviors that seem to depend on what
kind of graphics card you use:

- vectors not draping properly on some machines
see
http://skagit.meas.ncsu.edu/~helena/grasswork/grassprobl/
ccvectdrape.jpg and ccvectdrapenv.jpg

- multiple surface overlay changes with distance
compare
http://skagit.meas.ncsu.edu/~helena/grasswork/grassprobl/
overlayclose.jpg and overlayfar.jpg (these are the same surfaces,
I only zoomed-out)

- clip works differently on dif. machines - farther views are
still heavily clipped on some machines, but there are no problems on
others.

I will investigate here more - I have 5 different graphics
cards to try it on so I should be able to tell where it works
and where it does not, although I am not sure whether anything
can be done about it.

thank you once more (the handy help button is great too - we can help
with tutorial updates if you want and I definitely need to update the
TODO-BUGS
list)

Helena

Bob Covill wrote:

Markus,

I have attached the updated NVIZ files for you to look at. I just
grabbed the files that CVS was telling me had changed.

This should have the white background at startup, plus other changes
previously mentioned.

I have enabled the 3D-View stuff (no compile flag). It seems to be
working. I am sure there will be some issues with it. One of the biggest
problems is that there is currently no way to update the GUI to match
the loaded 3D view. The "load state" option does this but it is
resrictive to that file format. On my ToDo list is write a function that
sets the GUI from the current scene.

I have added another Help option to the GUI. I converted the TODO / BUGS
file to HTML and moved it into the html directory. There is now a link
to this from the GUI. The idea is that we can update Helena's list
sometime, and give users a good idea of what is and what is not working.
In doing this I noticed that alot of the HTML in the existing tutorial
needs a lot of cleaning. Add to the ToDo is update manual and tutorial.

Let me know if you have any questions.
--
Bob Covill

Tekmap Consulting
P.O. Box 2016
Fall River, N.S.
B2T 1K6
Canada

E-Mail: bcovill@tekmap.ns.ca
Phone: 902-860-1496
Fax: 902-860-1498

  ------------------------------------------------------------------------
                          Name: nviz_new.tar
   nviz_new.tar Type: Unix Tape Archive (application/x-tar)
                      Encoding: base64
               Download Status: Not downloaded with message

                          Name: ogsf_new.tar
   ogsf_new.tar Type: Unix Tape Archive (application/x-tar)
                      Encoding: base64
               Download Status: Not downloaded with message

2

On Thu, 27 Feb 2003, Helena wrote:

I did not have a chance to test thoroughly the load/save 3d view option
although it seems to work OK (except for the GUI update) - maybe
somebody who uses 3dview could test it further.

This is a coincidence as I was looking at that yesterday, although I
didn't test any of the other new features. I found that I needed to set
the height and exaggeration manually to the same values as in the 3dview
file before loading it; these weren't updated. But after doing that it
worked all right, apart from one bug relating to the interpretation of the
twist (i.e. roll) angle in the 3dview file.

A) The value is already stored in 10ths of degrees in the 3dview file so
it doesn't need to be scaled when reading it in [nviz save 3dview already
took account of this so load/save aren't consistent]

B) In the geoview struct a comment says the direction of rotation is
right-handed, i.e. clockwise facing away from the origin. But both d.3d
and SG3d interpret the value as a twist in the (unconventional)
anti-clockwise direction. As this seems to be the GRASS convention
therefore I think nviz should be changed to take account of this- simply
putting a minus sign in front of the value saved / loaded from the 3dview
file. [nviz load and save 3dview were both consistent in this regard, but
files saved by nviz weren't consistent when viewed in SG3d or d.3d].

Another issue is that the geoview struct used by nviz stores the twist and
field of view angles (and possibly others) in an int data type, whereas in
the 3dview stuct they are floats. As they are in 10ths of degrees the
maximum precision is only 0.1 degree. This loss of precision might be
significant for some applications. Does anybody know why they are ints in
nviz? To slightly reduce the effects of this anyway I could change the
code so it properly rounds the floats from the 3dview file to the nearest
int, instead of just truncating them with an (int) cast.

I have already fixed these bugs in my local version so if there are no
objections I will commit the changes to CVS later.

BTW it is really good that the nviz updates are now in CVS where everyone
can work on them and not have to worry about updating old versions of the
files or changes being lost (this put me off trying to change anything
before). Very good work by Bob.

Paul

3

On Fri, 28 Feb 2003, Paul Kelly wrote:

B) In the geoview struct a comment says the direction of rotation is
right-handed, i.e. clockwise facing away from the origin. But both d.3d
and SG3d interpret the value as a twist in the (unconventional)
anti-clockwise direction. As this seems to be the GRASS convention
therefore I think nviz should be changed to take account of this- simply
putting a minus sign in front of the value saved / loaded from the 3dview
file. [nviz load and save 3dview were both consistent in this regard, but
files saved by nviz weren't consistent when viewed in SG3d or d.3d].

Sorry, looks like I was slightly mistaken on this. Actually d.3d ignores
the twist value and uses the default of 0. And a comment in the definition
of the 3dview struct also says the direction of rotation should be
clockwise. So it looks like the bug is in SG3d, or maybe a 'feature' as it
has been there so long. In the SG3d GUI the 'twist' dial definitely
appears to be upside down, so presumably there is a reason for it.

So I will wait for futher insights into this, but will go ahead and fix the
scaling and rounding bugs now.

Paul