You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
(6) |
Nov
(9) |
Dec
(4) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(6) |
Feb
(6) |
Mar
(13) |
Apr
(10) |
May
(4) |
Jun
(5) |
Jul
(2) |
Aug
(5) |
Sep
(2) |
Oct
(6) |
Nov
(7) |
Dec
(8) |
2002 |
Jan
(3) |
Feb
(6) |
Mar
(2) |
Apr
(8) |
May
(4) |
Jun
(4) |
Jul
(4) |
Aug
|
Sep
(4) |
Oct
(15) |
Nov
(4) |
Dec
(2) |
2003 |
Jan
(5) |
Feb
(9) |
Mar
(8) |
Apr
(6) |
May
(1) |
Jun
(7) |
Jul
(10) |
Aug
|
Sep
(7) |
Oct
(11) |
Nov
(3) |
Dec
(6) |
2004 |
Jan
(15) |
Feb
(7) |
Mar
(5) |
Apr
|
May
(7) |
Jun
(4) |
Jul
(4) |
Aug
|
Sep
|
Oct
(6) |
Nov
|
Dec
(1) |
2005 |
Jan
|
Feb
(3) |
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
2006 |
Jan
(9) |
Feb
(2) |
Mar
(1) |
Apr
(2) |
May
(10) |
Jun
(45) |
Jul
(65) |
Aug
(62) |
Sep
(62) |
Oct
(25) |
Nov
(1) |
Dec
(11) |
2007 |
Jan
(25) |
Feb
(22) |
Mar
(15) |
Apr
(18) |
May
(9) |
Jun
(9) |
Jul
(59) |
Aug
(20) |
Sep
(1) |
Oct
(11) |
Nov
(6) |
Dec
(1) |
2008 |
Jan
(1) |
Feb
(15) |
Mar
(38) |
Apr
(3) |
May
(14) |
Jun
(3) |
Jul
(19) |
Aug
|
Sep
(2) |
Oct
|
Nov
(2) |
Dec
(6) |
2009 |
Jan
(27) |
Feb
(28) |
Mar
(1) |
Apr
(3) |
May
|
Jun
(1) |
Jul
(2) |
Aug
(2) |
Sep
(11) |
Oct
(2) |
Nov
(9) |
Dec
(5) |
2010 |
Jan
|
Feb
(1) |
Mar
(4) |
Apr
(1) |
May
(6) |
Jun
(13) |
Jul
(2) |
Aug
(1) |
Sep
|
Oct
|
Nov
(2) |
Dec
|
2011 |
Jan
|
Feb
(7) |
Mar
(2) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(6) |
Oct
(1) |
Nov
(10) |
Dec
(7) |
2012 |
Jan
(8) |
Feb
(9) |
Mar
|
Apr
|
May
|
Jun
(5) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
(7) |
Feb
|
Mar
(1) |
Apr
(2) |
May
(2) |
Jun
(1) |
Jul
(41) |
Aug
(1) |
Sep
|
Oct
|
Nov
(2) |
Dec
|
2014 |
Jan
|
Feb
(6) |
Mar
(46) |
Apr
|
May
(3) |
Jun
(3) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(3) |
2015 |
Jan
(1) |
Feb
(1) |
Mar
(16) |
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
(5) |
Oct
|
Nov
|
Dec
(17) |
2016 |
Jan
(3) |
Feb
(6) |
Mar
|
Apr
(12) |
May
(15) |
Jun
(2) |
Jul
|
Aug
(5) |
Sep
(17) |
Oct
(3) |
Nov
|
Dec
(6) |
2017 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
(13) |
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
(5) |
Nov
(2) |
Dec
(4) |
2018 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
(17) |
Aug
(4) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
2019 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(7) |
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
(4) |
Nov
(1) |
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
(1) |
May
|
Jun
(2) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
From: Neeti V. <nv...@ci...> - 2001-12-11 19:32:31
|
Hello Eeveryone, I am trying to install geomview on Linux m/c but while doing "make" a whole bunch of error comes in. I would highly appreciate if someone can tell me what is the exact procedure for installing it and what all compilers are needed for installation on Linux/Solaris. Thanks Neeti |
From: Tamara M. <tam...@co...> - 2001-12-04 22:55:58
|
> innocent question - I accidentally left a GV_BEGIN out > so that there's one extra )\n from the unmatched GV_END. > After that script is loaded (at pretty much normal > speed - little difference for only three satellites) _everything_ in > Geomview slows down and satellites are rendered one by one, even > though they're correctly topped and tailed with (progn ). > Now, with an unmatched opening (progn, I'd expect problems. > Surely a )\n without a matching (progn\n should just be ignored by > Geomview? Or am I suddenly running everything up a level in a lispish > stack with unpredictable results? Hmm. I'm guessing the latter. If your parens/braces don't all match up, Geomview can get very confused. You just happen to be lucky enough that it kept going instead of complaining about unparseable commands. > I imagine there's a better example of how to do this [binary format > stuff] in Geomview itself. Nope, I think that all of the modules we distribute (or even used to distribute in v1.6) communicate in ASCII. I know Ken Brakke's Surface Evolver uses binary format, since it's sending huge lists of polygons over as it evolves complex surfaces towards minimality. > FILE *gv_out; > gv_out = stdout; > [..] > fflush(gv_out); > > does judicious use of fflush() on the output pipe help? (I'm beginning > to think I've just thrown flushes in at random.) Yeah, fflush is critical! I forgot to mention that forgetting this as a common problem. You should absolutely do a fflush on every frame, right after your outermost progn. Cheers, Tamara |
From: Tamara M. <tam...@co...> - 2001-12-04 22:42:44
|
Sean Peisert writes: > I need to create a 2D or 3D mesh with medium-sized, differently > colored vertices, connected by lines, without surfaces. Most of the > examples don't seem to combine all these elements. Does someone have > an OOGL example they can pass to me? One of the reasons this is a confusing issue is that there are so many ways you might do this. You can get points either as a VECT segment of length 1 or as an OFF face with one vertex. (Note that points are drawn as round circles which always face the camera when the linewidth is greater than 1.) Similarly, you can get lines as either a VECT segment or as an OFF face of two vertices. You can also see lines without surfaces by turning off face drawing and turning on edge drawing of any of the OOGL primitive geometric types. So, there are a bunch of ways you might think you could do this: - wrong: a single OFF file that has 1-gons (points) and 2-gons (lines) problem: you can't differentially set linewidths for the points and edges, so you can't see the points stick out from the lines. - wrong: an OFF file that has 1-gons (points) and normal n-gons for faces, with face drawing off and edge drawing on through appearances. problem: turning off the face drawing will turn off not just the polygon surfaces but also the points, since they're considered faces too. - right: a LIST file with two OFFs, one for 1-gon points and one for 2-gon edges, with linewidths set differently for them through appearances. there's an example below. - right: a LIST file with two VECTs, one for 1-gon points and one for 2-gon edges, with different linewidths. - right: LIST with one VECT and one OFF. the minor advantage being that you could turn off the face drawing of the points separately from the vect drawing of the lines, if you care. (I think. Didn't bother testing it.) - right: two separate OFF files, sent to Geomview as two different pieces of geometry. Then you can control stuff like the linewidth from the appearance panel. In example below, instead of {LIST { appearance ... COFF ... } { appearance ... OFF }} you'd have (progn (geometry verts { appearance ... COFF ... }) (geometry lines { appearance ... OFF }) ) An issue with all the right ways is you do end up sending over the point info twice, but I can't think of a way around this offhand. My example has OFFs, since I find the VECT format particularly irritating. The final question is how to assign colors in the OFF format. You can either attach colors to the vertices (with a header of COFF), or you can attach colors to the faces (with a header of OFF). The first OFF below is an example the former, the second is an example of the latter. Of course, if you don't want differently colored edges, you can just have an OFF with no colors. You can set them all at once with the appearance panel using the face color button. (Although you may be thinking of these as "edges", Geomview has been told about faces - these faces just happen to be lines not surfaces.) By the way, you'll notice that I've used RGBA colors not RGB colors. According to the spec either should work, but I got a load error when I tried using just RGB colors at the vertices. Not something I have time to track down now. And a final note - since this example happens to be a cube, make sure you turn off bounding box drawing to avoid confusion between the bounding box edges (which will all be black) and the cube edges (which are colored). Hope this helps, Tamara --- Tamara Munzner, Compaq Systems Research Center tam...@co..., 650-853-2253 http://graphics.stanford.edu/~munzner ---------- {LIST { appearance { +linewidth 20} {COFF 8 8 12 # vertices have RGBA color info -0.5 -0.5 -0.5 1 0 0 1 # 0 red 0.5 -0.5 -0.5 0 1 0 1 # 1 green 0.5 0.5 -0.5 0 0 1 1 # 2 blue -0.5 0.5 -0.5 1 1 0 1 # 3 yellow -0.5 -0.5 0.5 0 1 1 1 # 4 cyan 0.5 -0.5 0.5 1 0 1 1 # 5 magenta 0.5 0.5 0.5 .5 .5 .5 1 # 6 grey -0.5 0.5 0.5 0 0 0 1 # 7 black # "faces" are actually points 1 0 1 1 1 2 1 3 1 4 1 5 1 6 1 7 } } { appearance { +linewidth 3 } {OFF 8 12 12 -0.5 -0.5 -0.5 0.5 -0.5 -0.5 0.5 0.5 -0.5 -0.5 0.5 -0.5 -0.5 -0.5 0.5 0.5 -0.5 0.5 0.5 0.5 0.5 -0.5 0.5 0.5 # "faces" are actually lines, and have RGB colors attached 2 3 2 1 1 1 1 2 2 1 1 1 1 1 2 1 0 1 1 1 1 2 0 3 1 1 1 1 2 4 5 1 1 1 1 2 5 6 1 1 1 1 2 6 7 .2 .5 .8 1 2 7 4 .2 .5 .8 1 2 3 7 .2 .5 .8 1 2 6 2 .2 .5 .8 1 2 1 5 .2 .5 .8 1 2 4 0 .2 .5 .8 1 } } } |
From: Tamara M. <tam...@co...> - 2001-12-04 20:24:04
|
Lloyd Wood writes: > One of the tricks that SaVi uses to get a speedup is to group all > drawing updates sent to Geomview within a > (progn\n > blah blah blah > )\n > > so that Geomview doesn't do anything until the program ends, then > applies all the updates to the camera at once. (I presume that you > can nest progn's, and that this wasn't just a fortuitous hack...) Yup, that's correct - you can indeed nest progn's, and it's definitely a good thing to batch up all geometry changes before redrawing. That's definitely the first thing to try. If batching with progns doesn't increase your framerate to the desired level, you could try using binary instead of ASCII communications with Geomview. Although ASCII is much nicer for humans to read for debugging and such, if you're sending over a *lot* of geometry data on every frame you will see a significant speedup from using binary. See http://geomview.sourceforge.net/docs/html/geomview_33.html#SEC36. If you do this you should be aware of the bugs/issues about endianness that were discussed in April and November, see the list archives at http://www.geocrawler.com/archives/3/5646/2001/11/0/ http://www.geocrawler.com/archives/3/5646/2001/4/0/ Finally, another thing that can be useful is to make sure that the external module isn't sending information to Geomview faster than Geomview can render it. It's only really an issue if you need to have bidirectional communication between Geomview and the module - in that case it's irritating to give a command, and then not see its results for many seconds because Geomview is so far behind in processing the commands from the module. So if that's the case for you, then you'll want to wait to send the next frame of information until you get an acknowledgement back from Geomview that it's processed the data from the previous frame. You do this by having a loop like this: - send command to geomview to take one animation step, or draw one frame - send "(echo ok\\n)" - wait for "ok" to come back (the module sees it arrive on standard input) - send another command, etc. or, for a more-efficient variant, you could send the "echo" *before* the command(s) that do the work, so that you'd feel free to send another command as soon as work has *begun* on the previous one. Hope this helps, Tamara --- Tamara Munzner, Compaq Systems Research Center tam...@co..., 650-853-2253 http://graphics.stanford.edu/~munzner |
From: Franco A. B. <abi...@un...> - 2001-12-04 13:46:53
|
Hermann Pleteit wrote: > "Franco A. Bignone" wrote: > > > > I have been using Geomview for several years, and installing it on > > AIX machines and Linux, but I got stuck > > with the last version on a new machine (RedHat7.0). > > > > I downloaded the 1.8.0 and 1.8.1 and installed as usual, set the > > > > GEOMROOT=/usr/local/Geomview > > > > and so on, but when I try to start I get the message that the file > > > > /usr/local/bin/geomview: /usr/local/Geomview/bin/linux/gvx: File or > > directory not found > > > > but /usr/local/Geomview/bin/linux/gvx: is there with the right > > permissions .... any hint ? Any > > compatibility problem with RedHat 7.0 ? > > > I guess you should install the older version of the shared c-library > (libc5) on your system in addition to libc6 which you are probably using > now. Once I had the same strange error when installing Maple on my > system and it could be fixed that way. > > Hermann Thanks for your replies. I fixed it. The silly reason, if I have understood it correctly, as usual when you try to fix something you may be slipping some unknown bug somewhere, I was trying both the geomview distribution and the *.rpm distribution for RedHat. In this second case the build up of geomview is done in /usr/share (as with most programs in RedHat), so basically I had two gvx, and apparently this was causing the problem. Once I figured it out, deinstalling all of it, and using one of them clean from scratch I got it working again. This has been a problem several times with RedHat, you have always to be careful with stuff that goes into /usr/local because often things are screwed up by this /usr/share business. Moreover if you use, as I do, two different Unix (AIX-Linux) the paths are always different. I could try to see how it goes with SUSE, but I am not that masochistic. Here is the story, the normal path for geomview is completely changed: sh -x /usr/bin/geomview + GEOMROOT=/usr + GEOMVIEW_GVX=/usr/libexec/geomview/gvx + export LD_LIBRARY_PATH + MACHTYPE=linux + suf= + : /usr/share/geomview + : .:/usr/share/geomview/geom:/usr/share/geomview + : /usr/libexec/geomview + : /usr/share/geomview/.geomview + export GEOMROOT GEOMVIEW_GVX GEOMVIEW_LOAD_PATH GEOMDATA GEOMVIEW_EMODULE_PATH GEOMVIEW_SYSTEM_INITFILE + gvx=/usr/libexec/geomview/gvx + gvx_option + test + gvx_option '' + test + '[' linux = solaris -a -z '' -a -w /dev/fbs/ffb0 ']' + '[' -f /usr/libexec/geomview/gvx ']' + GEOMVIEW_GVX=/usr/libexec/geomview/gvx + export GEOMVIEW_GVX + exec /usr/libexec/geomview/gvx But it works, as far as I am concerned. As usual "standards are nice because everybody can have its own" Tx a lot. Ciao Franco -- ************************************************************************* * Dr. Franco A. Bignone, I.S.T., National Cancer Institute, Lab. Exp. * * Oncology, Lr.go Rosanna Benzi, 10, 16132, Genova, Italy. * * e-mail: fra...@is..., abi...@un... * * http://gendyn.ist.unige.it * * ph. home: +39-010-247-3070 (answ.) * * job: +39-010-5600-213, +39-010-355839, +39-010-5600641, * * fax: +39-010-5600-217 * ************************************************************************* |
From: Casteleijn, A.A. <cas...@nl...> - 2001-12-04 06:19:03
|
Halloo, I'm working for the Dutch aerospace lab. in the space department. We are using Geomview to visualise space craft movements in space, by = downing this I discover that there is a limitation in the speed, of information that can be past from a emodule to = geomview. Can you tell me what the max speed is and what I have to do to make this = higher (10 Hz). Ton Casteleijn. |
From: Mark P. <mb...@ge...> - 2001-12-03 22:00:43
|
> Am I right in thinking that http://www.geom.umn.edu/ finally > died during thanksgiving weekend? If so... Almost, but it's not dead yet, I hope. It had a disk crash and is currently waiting for someone to go tend to it. Its disks are mirrored, so there's a good chance that we'll be able to bring it back online, once someone is able to go tend to it. I'm currently 1300 miles away, so I can't do it myself; I've made arrangements for a friend to do it, and hopefully he'll have time later this week. Everyone keep your fingers crossed... --Mark |
From: Franco A. B. <abi...@un...> - 2001-12-03 17:34:15
|
I have been using Geomview for several years, and installing it on AIX machines and Linux, but I got stuck with the last version on a new machine (RedHat7.0). I downloaded the 1.8.0 and 1.8.1 and installed as usual, set the GEOMROOT=/usr/local/Geomview and so on, but when I try to start I get the message that the file /usr/local/bin/geomview: /usr/local/Geomview/bin/linux/gvx: File or directory not found but /usr/local/Geomview/bin/linux/gvx: is there with the right permissions .... any hint ? Any compatibility problem with RedHat 7.0 ? Tx a lot Franco -- ************************************************************************* * Dr. Franco A. Bignone, I.S.T., National Cancer Institute, Lab. Exp. * * Oncology, Lr.go Rosanna Benzi, 10, 16132, Genova, Italy. * * e-mail: fra...@is..., abi...@un... * * http://gendyn.ist.unige.it * * ph. home: +39-010-247-3070 (answ.) * * job: +39-010-5600-213, +39-010-355839, +39-010-5600641, * * fax: +39-010-5600-217 * ************************************************************************* |
From: Sean P. <spe...@al...> - 2001-11-28 01:55:02
|
I need to create a 2D or 3D mesh with medium-sized, differently colored vertices, connected by lines, without surfaces. Most of the examples don't seem to combine all these elements. Does someone have an OOGL example they can pass to me? Thanks, Sean |
From: Hinke M O. <H.M...@br...> - 2001-11-13 12:33:44
|
> I am using Geomview for my master thesis. I use it to > view a scene of triangles in 3D. I have one little > problem, and that is printing the camera view. > > I saved the view as postscript. The convertion to postscript > applied some z-order on the triangles in the scene. This was > disastrous since some of the triangles are intersecting. > > I saved the view to PPM file, but the result was a granular > picture, that was unacceptable for me. > Capturing the scene with xv gave similar results. > I am using this magic formula that Stuart Levy once gave me: (snapshot focus "| pnmscale .5 | pnmtotiff > picture.tiff" ppm 1800) You type this command in the Command window, which is an item under the Inspect menu. Focus is the camera, the picture is "blown up" to 1800x1800 pixels (so it works regardless how small the window is) and saved with a scaling factor of .5 to picture.tiff in tiff format. The resulting picture is, thus, 900x900 pixels. This leads to a very big picture of high quality: all surfaces have very smooth edges (if they are supposed to have those) and intersections of polygons are rendered smoothly. You can make the final size smaller by decreasing the number 1800. I tend to use a thick linewidth (lines 6, points 15 or so) and reduce the size only in the text-file. Happy printing, Hinke Osinga. |
From: Hayim S. <Ha...@ex...> - 2001-11-12 08:49:49
|
Hello all, I am using Geomview for my master thesis. I use it to view a scene of triangles in 3D. I have one little problem, and that is printing the camera view. I saved the view as postscript. The convertion to postscript applied some z-order on the triangles in the scene. This was disastrous since some of the triangles are intersecting. I saved the view to PPM file, but the result was a granular picture, that was unacceptable for me. Capturing the scene with xv gave similar results. At this point I tried to upgrade to Geomview 1.8.1. For this I downloaded Mesa-4.0 and openmotif. The compilation and installation went fine. When I ran geomview it crashed. I looked at the core to examine the stack. It crashed when trying to allocate 24 bytes. The calling stack was as follows: main -> init_geomview -> drawer_init -> comm_object -> fstropen -> CC_fmemopen -> streambuf::streambuf -> new I tried it also with Geomview 1.7.10 and Mesa-3.5. Same result. I'm running RedHat 6.2, compiling with egcs-1.1.2. Remember that my original problem was obtaining sharp images of the view. Making Geomview 1.8.1 work is less critical for me. Have you encountered such a problem? Does anyone know how to produce sharp printable images? Thanks, Best regards, Hayim Shaul. |
From: Stuart L. <sl...@nc...> - 2001-11-05 18:45:13
|
Hey, Lloyd! I'd suggest something like the following. Testing macros is not the easiest way, and as you and Steve say, binary I/O was broken in some versions of Geomview (for some GLIBC versions) until 1.8.1. You can check Geomview version at run time. It sounds good to offer a user choice, and you could use a test to see whether it was bound to fail (and if so, force the choice off). This should do: int uses_ieee_float() { static float testfloat = 40970.25; static unsigned char testle[] = { 0x40, 0x0a, 0x20, 0x47 }; static unsigned char testbe[] = { 0x47, 0x20, 0x0a, 0x40 }; if(sizeof(testfloat) != 4) return 0; /* wrong float size */ if(memcmp( &testfloat, testle, 4 ) == 0) return 1; /* OK, little-endian */ if(memcmp( &testfloat, testbe, 4 ) == 0) return 1; /* OK, big-endian */ return 0; /* non-IEEE, or something */ } and if this failed, then refuse to allow binary I/O. (The funny number was chosen so that all four bytes are different, which makes the endian-ness test pretty safe, and makes it hard for any non-IEEE format to pretend to be IEEE.) If it succeeded, and geomview was older than 1.8.1 (as detected by scanning the result of something like (echo (geomview-version) "\n") ) then you might also refuse, or at least turn it off by default. Otherwise turn it on. > If non-IEEE includes greater precision than IEEE specifies, I > suppose there might be a few... There are some oddballs, like Cray and VAX hardware, that don't. Also it's conceivable someone might have a "float" value of some unusual length, like 8 bytes (e.g. float == double). > The SaVi code (take a look in 1.0's src/satellites.c and > src/gv_utils.c - the test is in src/include/gv_utils.h) has some > #ifdef hacks I don't fully understand > (htons_buffer(), htonl_buffer()) that do > the big-endian conversion if the compiler decides it's running on a > littleendian processor, otherwise they're empty routines > that don't manipulate the buffer. Oh good, I thought we'd put in something like that. I worked with Patrick to get the binary I/O code going, but it was a long time ago. > Presumably Geomview on littleendian does a similar conversion at the > other end to stuff the results back into littleendian locations - I > haven't looked into Geomview's code. Yes. (But it doesn't do any fancy IEEE-format test like the above.) > The code appears to be valid, but the test does not appear to have > kept pace with Pentiums/compilers. Of the conditions you listed, I think WORD_BIT may be the one that's not always available: there's no such thing in the header files on my Linux system. To get the others, you'd need <limits.h> and <float.h>. Maybe a compile-time check for integer size could be #include <limits.h> #if (INT_MAX == 2147483647) && ... but you might as well put in a run-time check. > (There's no way of setting up a littleendian pipe and circumventing > conversion at both ends for speed?) No. But byte-swapping is cheap. Stuart |
From: Steve M. R. <ste...@vi...> - 2001-11-05 01:54:08
|
On Sun, Nov 04, 2001 at 10:01:19PM +0000, Lloyd Wood wrote: > Hi, > > What do you recommend as a valid compiler test to see if Geomview > binary format can be used directly with internal formats or not? By "internal formats", you mean the processor-native integer and floating point formats? Test for endianness: geomview "binary format" is defined as big endian. IEEE format is used for I/O of floating point numbers, so for completeness you'd also need to ensure the system uses IEEE floating point though I don't expect there are many non-IEEE machines about these days. > but the ifdef'd optional binary-format-generating code surprisingly > does not get run on my Red Hat 7 PIII unless I force selection with: > #define USE_GV_BINARY_FORMATS > ...at which point that code is compiled in and subsequently works > fine. That's a bit odd: intel is little endian, so you shouldn't be able to use native format on that platform. > I'm using red hat's gcc/egcs 2.96 variant and Geomview 1.8.1, > which I gather from the revision history fixed binary format handling > on linux - so perhaps avoiding using binary format completely is a > Good Thing as far as any installed Geomview base is concerned? I tend to agree; I use text files unless they are really huge. For one thing, there is a problem with some versions of geomview on little-endian machines. For another, it is much easier for humans to read input files if they are not binary. ;-) -S -- by Rocket to the Moon, by Airplane to the Rocket, by Taxi to the Airport, by Frontdoor to the Taxi, by throwing back the blanket and laying down the legs ... - They Might Be Giants |
From: Tamara M. <tam...@co...> - 2001-11-01 23:07:07
|
Michael S. Jolly writes: > Does anyone out there know of software to take a .off file > and optimize the mesh? I have several surfaces which have many > vertices (even over smooth portions) and as a consequence are > difficult to manipulate in Geomview. What you want is known under a bunch of names - level of detail, reduction/decimation/simplification of polygons/meshes, etc. There are many tools floating around that will do this. The challenge is to find the one that you can use with the least amount of work. http://mkrus.free.fr/CG/LODS/ lists several programs that might work. Their list includes the Garland/Heckbert work that Paul Allen mentioned in his reply. Some of the simplification programs out there are intended to work on data structures, but you probably want the ones that act on files in some particular 3D data format. I don't know offhand of one that can directly handle the OFF file format, but there are definitely some that can do VRML 1.0. You can translate between OFF and VRML1 using the oogl2vrml and vrml2oogl binaries that come with the Geomview distribution. Another thing to keep in mind is that you could do a 2-hop conversion chain, from OFF->VRML1->X where X is something like 3DS or DXF. See the converter list at http://home.hiwaay.net/~crispen/vrmlworks/convert.html. Try looking into Lodestar, which does simplification on vrml1.0 files: http://www.cg.tuwien.ac.at/research/vr/lodestar/ Hope this helps, Tamara --- Tamara Munzner, Compaq Systems Research Center tam...@co..., 650-853-2253 http://graphics.stanford.edu/~munzner |
From: Paul A. <al...@nw...> - 2001-11-01 03:43:34
|
"Michael S. Jolly" wrote: > > Does anyone out there know of software to take a .off file > and optimize the mesh? I have several surfaces which have many > vertices (even over smooth portions) and as a consequence are > difficult to manipulate in Geomview. I've been using the "scape" program from Michael Garland and Paul Heckbert for essentially that purpose. The README in my copy is dated 1994, but it still does what I need. You can find out about it at: http://www-2.cs.cmu.edu/afs/cs/user/garland/public/scape/ I use scape as a component in my terrain visualization gizmo. You basically give it a mesh and the number of vertices you want in the result, and it minimizes the surface error at each vertex. The problem is that it reads and writes files in its own format. My software translates SDTS DEM data into an internal representation, optionally passes the data through scape for simplification, and then writes it out in OFF format for Geomview or passes it directly to a Maverik VR window for visualization. I found scape by searching for "terrain simplification" on the Web. Google's first several hits for that string are all related to scape or a newer thing called "terra" from the same researchers. Paul Allen |
From: Michael S. J. <ms...@in...> - 2001-10-31 16:24:25
|
Dear Geomview Users, Does anyone out there know of software to take a .off file and optimize the mesh? I have several surfaces which have many vertices (even over smooth portions) and as a consequence are difficult to manipulate in Geomview. Thanks, Mike |
From: Mark P. <mb...@ge...> - 2001-10-23 05:20:30
|
> Just to report that this did not work with version 1.6.1 but now works > with version 1.8.1. For others on the list who are reading this (or reading it later in the archives), I'll add that when writing scripts to drive Geomview in batch mode, be sure to refer to the camera with the name "default" rather than "c0". If you use "c0", Geomview will open a camera window in spite of the "-wins 0" option. --Mark |
From: Stephane P. <s.p...@ni...> - 2001-10-23 04:49:44
|
Mark Phillips writes: > > Is their an option/gcl command which causes geomview to run REALLY in > > batch mode? > > Actually there is a way to get a completely windowless geomview: > > % geomview -nopanels -wins 0 > > or, more usefully, > > % geomview -nopanels -wins 0 -c GCL_FILE Hi Mark, Just to report that this did not work with version 1.6.1 but now works with version 1.8.1. Thanks for your help, Stephane |
From: Mark P. <mb...@ge...> - 2001-10-19 19:59:35
|
> Is their an option/gcl command which causes geomview to run REALLY in > batch mode? Actually there is a way to get a completely windowless geomview: % geomview -nopanels -wins 0 or, more usefully, % geomview -nopanels -wins 0 -c GCL_FILE which will cause Geomview to run the GCL commands in GCL_FILE (which can be '-' if you want to pipe commands via stdin). One thing to note is that even though this starts a process that creates no windows, it does actually require a connection to an X server. That's not a problem if you're running it on a machine that you're sitting at and on which X is running. But if you're trying to run it on a remote machine, or on a machine on which X windows doesn't run (like, for example, a web server), then you'll have to specify a X display via the DISPLAY environment variable in the shell before running Geomview, as in (for Bourne shell): % export DISPLAY=<MY_XHOST>:0.0 % geomview -nopanels -wins 0 -c GCL_FILE where <MY_HOST> is the name (or IP address) of a machine running X windows --- AND to which you have permission to make X connections. --Mark Mark Phillips @ Geometry Technologies, Inc. 608 Humboldt Ave., St. Paul, MN 55107 Phone: 651-222-4632 Fax: 651-292-0014 mb...@ge... http://www.geomtech.com |
From: Tamara M. <tam...@co...> - 2001-10-19 19:10:22
|
Stephane Popinet writes: > I would like to use geomview in purely batch mode to automatically > generate postscript figures from OOGL files in scripts etc... > > I managed to do pretty much what I want using a GCL script. However, I > didn't find how to prevent geomview from displaying the "Camera" > window. I already use the "-nopanels" option but it does not prevent > the "Camera" window from being displayed... > > So I run my script and the "Camera" window pops up for two seconds, > the time for geomview to create a postscript snapshot... annoying really. > > Is their an option/gcl command which causes geomview to run REALLY in > batch mode? To the best of my knowledge Geomview does insist on popping up a window no matter what. But, you can make this window very small and out of the way, so that it doesn't bother you. Since PostScript (and PPM, for the record) rendering is done offscreen, the size of the window on your screen can be only a few pixels even though you're creating a picture at much higher resolution. Here's an example batch file that opens up a very small window down in the corner of my screen, which I don't notice it unless I'm specifically looking for it: (progn (camera default { camtoworld transform { -0.89896667 0.16900851 -0.40410414 0 0.43307546 0.48121688 -0.76215452 0 0.0656505 -0.86015731 -0.50578946 0 1.2306064 -16.264462 -9.6162682 1 } perspective 1 stereo 0 fov 40 frameaspect 1 focus 3 near 0.07 far 100 } ) (window default { position 0 1 0 1 } ) (camera c0) (geometry foo { <hdodec.off }) (redraw c0) (draw c0) (snapshot c0 /tmp/foo1.ps ps 300 300) (geometry foo { <csquare.quad }) (transform world world world rotate .1 0 0) (redraw c0) (draw c0) (snapshot c0 /tmp/foo2.ps ps 300 300) (exit) ) Things to note are: use of the special "default" name for the camera/window, so that your settings affect the first camera window that Geomview creates, so that it doesn't flash a normal-sized window up during intialization. Then when you create the camera "c0" with no arguments, it has the attributes of that default camera, and you can use c0 for your snapshots. I have a vague memory that 'position' doesn't work properly on all platforms - if that's the case, then you could try the size command instead, since I'm pretty sure that should work everywhere: (window default { size 0 1 noborder } ) One more thing - perhaps you've already noticed this, but a really easy way to get the exact camera settings that you want is to interactively move the camera around with the usual mouse interface until you have just the right picture, and then just save off exactly that information to a file by picking 'Camera' instead of 'World' in the Save dialog box. Hope this helps, Tamara --- Tamara Munzner, Compaq Systems Research Center tam...@co..., 650-853-2253 http://graphics.stanford.edu/~munzner |
From: Stephane P. <s.p...@ni...> - 2001-10-18 23:07:28
|
Hello everybody, I would like to use geomview in purely batch mode to automatically generate postscript figures from OOGL files in scripts etc... I managed to do pretty much what I want using a GCL script. However, I didn't find how to prevent geomview from displaying the "Camera" window. I already use the "-nopanels" option but it does not prevent the "Camera" window from being displayed... So I run my script and the "Camera" window pops up for two seconds, the time for geomview to create a postscript snapshot... annoying really. Is their an option/gcl command which causes geomview to run REALLY in batch mode? Thanks for your help, Stephane |
From: Nathan H. <nj...@ha...> - 2001-09-10 23:47:10
|
On Mon, 10 Sep 2001, Guillaume SANTINI wrote: > Hi all, > > I'm a Mathematica user and I use Geomview to show molecule's in 3D. > I want to draw sphere for each atoms. > The Geomview.m and OOGL.m packages are only able to convert Lines or > Polygons primitives in Geomview language. At first it's seems to be OK > because Mathematica draws sphere as a set of Polygons. > My problem is that "my" molecules are very big, which need a lot of > calculus to show them as Polygon (for 1 sphere there're about 100 > vertices), and the result don't looks great compare with OpenGL sphere. > I search for somebody giving me a solution to export from Mathematica to > geomview OpenGL spheres objects. > More, I want to draw spheres of different colors. Rasmol(http://www.umass.edu/microbio/rasmol/) is specifically tuned to draw molecules. I would suggest that that would be a better tool than geomview. It is available for pretty much all platforms. There are many other viewers, rasmol is just the last one I used(admittedly back 5 years ago). njh |
From: Guillaume S. <sa...@ma...> - 2001-09-10 20:07:45
|
Hi all, I'm a Mathematica user and I use Geomview to show molecule's in 3D. I want to draw sphere for each atoms. The Geomview.m and OOGL.m packages are only able to convert Lines or Polygons primitives in Geomview language. At first it's seems to be OK because Mathematica draws sphere as a set of Polygons. My problem is that "my" molecules are very big, which need a lot of calculus to show them as Polygon (for 1 sphere there're about 100 vertices), and the result don't looks great compare with OpenGL sphere. I search for somebody giving me a solution to export from Mathematica to geomview OpenGL spheres objects. More, I want to draw spheres of different colors. In the same way if anybody know how to specify directly from Mathematica Thickness of Lines in Geomview, it would be great. Thanks for reading this message |
From: Gustavo O. <go...@ci...> - 2001-08-24 23:33:51
|
I want to install the Geomview in a RedHat 7.1 OS and I received the following message when trying to run: >geomview X Error of failed request: GLXBadDrawable Major opcode of failed request: 129 (GLX) Minor opcode of failed request: 5 (X_GLXMakeCurrent) Serial number of failed request: 1100 Current serial number in output stream: 1100 Somebody have any idea of what is going on??? Cheers Gustavo -- Dr. Gustavo Olague CICESE Research Center P.O. Box 434944 San Diego, CA 92143-4944 USA phone: +52.6.1745050 x 25402 fax: +52.6.1750549 e-mail: go...@ci... web: http://cienciascomp.cicese.mx/Pagina-Olague.htm |
From: Steve M. R. <ste...@vi...> - 2001-08-08 16:20:44
|
On Mon, Aug 06, 2001 at 08:10:42AM -0300, Joao B. Oliveira wrote: > > > The problem is, stdiostream.h does not exist under gcc 3.0... > > > it was provided with gcc 2.95.2, but not in later versions. > > > Is there a way to solve this problem? > > > > The quickest way is to compile using GCC 2.95.x. > > I see... Hmmm... > Although I surely could do that, there are any plans to > overcome this problem in a future release? Hello Joao, While I can't speak for the geomview project, I'm pretty sure this is something that will be fixed eventually. It may not be high on anyone's priority list at the moment, but the source is there and I'm sure a patch would be welcomed ;-) > It would be > necessary to install gcc 2.95.2 specially for that, and > every time geomview needs recompilation... it does not > seem very practical. I guess you could install both GCC 2.95.2 and GCC 3.0 and leave them both installed. GCC versions normally coexist peacefully. Alternatively, if you are using a *Debian* linux system, you needn't recompile geomview at all! I build debian packages for geomview, which are available at http://packages.debian.org/geomview. I thought that RPMs were available too, but I can't find them now. If there are no RPMs, you could try installing the debian package using "alien". -Steve -- by Rocket to the Moon, by Airplane to the Rocket, by Taxi to the Airport, by Frontdoor to the Taxi, by throwing back the blanket and laying down the legs ... - They Might Be Giants |