The collected works of Martin Steen - Page 1

Hello!

I just have released version 1.2 of the astronomical application "Die Planeten"
for Irix and Windows.

The homepage of the project is:
http://www.martin-steen.de/dieplaneten/ ... en-en.html

The main changes are:

- zooming with right mouse (important for original SGI mouse)
- Uranus ring
- Uranus- and Neptun moons
- Moon names
- Anaglyph mode ( http://www.martin-steen.de/dieplaneten/anaglyph/anaglyph-en.html )
- Version information ("about box")
- Improved textures for some planets
- JPEG-Textures instead of TGA, resulting in smaller files
- Language and planet settings are saved

For those who discover problems with missing GLUT-libraries, there is a link
to the nekoware glut package on the project homepage.

Best regards, Martin
Hi,

I just finished a little demo for Irix-machines.
It shows a spinning SGI-cube-logo using OpenGL.

http://www.martin-steen.de/sgi/3dlviewer-sgi.gz

The whole demo is compressed into a single executable file.
Just gunzip the file and start it. I have tested it on my Fuel
workstation. The picture below shows how the programm
should look like.

There are a few keys for interaction:
e - toggle environment-mapping
r - reset/toggle rotation
a - toggle anaglyph mode (red/cyan glasses required)
esc - quit
Left mousebutton + mousemove: rotate
Right mousebutton + mousemove: zoom

Image
(3D model made with Wings3D)

Best regards, Martin

P.S.: if glut libraries are missing, install the nekoware glut package:
ftp://ftp.nekochan.net/pub/downloads/Ne ... s3.tardist
I know, I am late - but here is a cube I made with Wings3D:

http://www.martin-steen.de/sgi/sgi-logo.3ds

Best regards, Martin
@nekonoko: thank you for the blog report! :-) About the crash: there is no
crash on my own machines (fuel & octane). Strange.

@edefault:
@deBug: ok, I work on a new version where you can use your own image
and that has an improved rotation control.

@fzalfa: unfortunately, I don't know how to make a screensaver for Irix.
Maybe somefrom from the forum here knows.

Best regards, Martin
ramq wrote: No problem whatsoever on my funky R12k-300/V6 Octane2. It's a bit slow performing, but otherwise OK.
As with deBug, I get no segfaults.


It runs VERY slow on my Octane1. Without environment-mapping (press e to switch off),
it runs fast, but it looks only half as nice, of course ;)

ramq wrote: Question: Can you make the spinning controllable, like in the SGI-demo "powerflip"?


Where can I find that powerflip demo?

ramq wrote: And the last one... when will this hit Nekoware? :D


I will ask Joerg if he can help me with that.

Best regards, Martin
Hello,

People were asking for more features, so I give people what they want!
Next week I am on a vacation, so I had to finish it quick.

You can download the new version here:
http://www.martin-steen.de/sgi/3dlviewer-sgi.gz

New commandline options are:

-xrot = X-axis rotation only
-yrot = Y-axis rotation only
-zrot = Z-axis rotation only
-window = Start in window-mode
-map <image.tga> = change map (see notes)
-itsacow = ???

Also, the zoom-limit has changed so you can take a very close look at
the model.

About the map-feature: You can provide your own environment-map as
a Targa-file (.tga). Size must fit the OpenGL requirements
(e.g. 256x256 or 128x128 or 64x64 Pixels), depth must be 24 bit.
I made a 256x256 Pixel test image with "gimp" on my fuel and it
worked.

Example:

Code: Select all

3dlviewer-sgi -yrot -window -map myimage.tga

= start the demo with y-rotation in window-mode, using
"myimage.tga" for mapping.

Have fun, Martin
There is a Tezro at eBay/Germany:

http://cgi.ebay.de/SGI-TEZRO-2x700MHz-3 ... 31121a2488

The dealer is in Braunschweig (15 min from my home). But I suppose, 2200 € is to much.
Hello,

when I create a Motif fileselector box, it always has a blue background (see image),
but I would like to have a more common color (like grey).

Image

System: SGI Fuel
Is that a matter of system settings or do I have to tweak the colors in my app?

The sourcecode is:


Code:
#include <stdio.h>
#include <stdlib.h>
#include <Xm/FileSB.h>

int  main(int argc, char* argv[])
{
Widget        toplevel, dialog;
XtAppContext  app;
char* FileBoxName = "Select File";

if (argc == 2)
{
FileBoxName = argv[1];
}

XtSetLanguageProc (NULL, NULL, NULL);

toplevel = XtVaAppInitialize (&app, "Fileselector",
NULL, 0, &argc, argv, NULL, NULL);


/* Create a simple FileSelectionDialog -- no frills */
dialog = XmCreateFileSelectionDialog (toplevel, FileBoxName, NULL, 0);
XtAddCallback (dialog, XmNcancelCallback, (XtCallbackProc) cancel, NULL);
XtAddCallback (dialog, XmNokCallback, (XtCallbackProc) echo_file, NULL);

XtManageChild (dialog);
XtAppMainLoop (app);
return 0;
}


Greetings,
Martin
PymbleSoftware wrote:

Check out the X resources file... There should be documentation about it somewhere.. You can set values in the resources for stuff like selector background colours etc, from memory... its been a long time.. I have completed some raw Xt and Xm applications in the past but IRIX has a few little quirks that annoyed me enough to mess around with Qt4 (its in nekoware)

I think there a Motif specific across all widget classes one somewhere.
http://www.le.ac.uk/cc/dsss/docs/xcustom.shtml asserts possible to ascertain some of the resource names which can be used by referring to the documentation on the widget library. The OSF/Motif "Programmers Reference" is useful if doing this for Motif based programs.

You could also do it programatically.
Regan


Thank you for the hints and the links, I will give it a try.

I know that one can make a fileselector-box with Qt or GTK, but I don't want users to have to
install a bunch of libraries. AFAIK is Motif the "lowest common level" for Unix systems and it
works without installing additional libs (at least I hope so).

Best regards,
Martin
kramlq wrote:

The resource and value part can be very generic or more specific. For example
- "*.background: white" would make every widget background white, or
- "*XmBlah*.background: white", would make every instance of XmBlah's background white.


Thank you a lot! I will try this when I'm back home this evening.

I still wonder why the default-color is "light blue". But if I can manage to change the colors with
some Motif function calls, everything is great.

Best regards,
Martin
squeen wrote:
You also want to set the SGI Motif flag using

Code:
static String fallback_resources[] = {
"*sgiMode: TRUE",
"*SgNuseEnhancedFSB: TRUE",
"*useSchemes: all",
NULL
};


Will make everything look IndigoMagic-ish. :)


It works!
That fallback-argument did the trick. It seems like only the line
"*useSchemes: all" is needed to change the colors.

Thank you all for your help! It's great to have so many Motif-experts here around.

Best regards,
Martin

Image

(here is the final code. I added a XtVaSetValues call to set the dialog title
properly)

Code:
#include <stdio.h>
#include <stdlib.h>
#include <Xm/FileSB.h>

int  main(int argc, char* argv[])
{
static String fallback_resources[] =
{
"*sgiMode: TRUE",
"*SgNuseEnhancedFSB: TRUE",
"*useSchemes: all",
NULL
};

Widget        toplevel, dialog;
XtAppContext  app;
char* FileBoxName = "Select File";

if (argc == 2)
{
FileBoxName = argv[1];
}

XtSetLanguageProc (NULL, NULL, NULL);

toplevel = XtVaAppInitialize (&app, "Fileselector",
NULL, 0, &argc, argv, fallback_resources, NULL);

/* Create a simple FileSelectionDialog -- no frills */
dialog = XmCreateFileSelectionDialog (toplevel, FileBoxName, NULL, 0);
XtVaSetValues(XtParent(dialog), XmNtitle, FileBoxName, NULL);

XtAddCallback (dialog, XmNcancelCallback, (XtCallbackProc) cancel, NULL);
XtAddCallback (dialog, XmNokCallback, (XtCallbackProc) echo_file, NULL);

XtManageChild (dialog);
XtAppMainLoop (app);
return 0;
}
jan-jaap wrote:
Close, but no cigar. It's not as hideous as the blue version, but it still lacks the SGI scrollbar decorations and the drag-n-drop target. Here's the Nedit File->Open dialog:


Ok, that box looks better than the standard Motif box :cry:
But how can I create the Nedit fileselectorbox?

Best regards,
Martin
Attachment:
Enchanted_Ocean_On_Neptune_by_Fruechtebrot.jpg


Some of the pictures on my deviantart-page are rendered with my Fuel workstation.
http://fruechtebrot.deviantart.com
Geoman wrote:
@Martin Steen: this fractal rendering is done on a fuel? which software did you use?


I write my own software. The Fractal-Explorer is an OpenGL-Programm with a GUI that runs on
Windows or Linux, the renderer is a simple commandline-program that can run on every plattform
for which I have a C++ compiler.

Best regards,
Martin
Geoman wrote:
@Martin Steen: it's produces really nice images!


Thank you very much! :D
It's all about finding the right place deep in the "valley of seahorses" and then
using a good color mapping algorithm.

http://mathworld.wolfram.com/SeaHorseValley.html

Best regards,
Martin

@moderator: thank you for making the picture preview
Quote:
"*SgNuseEnhancedFSB: TRUE" should have activated the SGI style file selector box and given you the improved box....hmmm.
Try adding this to the widget's resources:

Code:
argcount=0;
XtSetArg( arglist[argcount], SgNuseEnhancedFSB, TRUE );argcount++;
XmCreateFileSelectionDialog( w, "openFileDialog", arglist, argcount );


Thank you for your help. But the additional code did not change anything.

I found the solution 10 Minutes ago on this page:
http://mecca.spd.louisville.edu/ebt-bin/nph-dweb/dynaweb/SGI_Developer/IIDsktp_IG/@ebt-link;cs=fullhtml;pt=1134?target=%25N%15_18455_START_RESTART_N%25#X

The trick is, that you have to add -lSgm to the linker-flags in the makefile.
Code:
LDFLAGS = -lSgm  -lXm -lXt -lX11


Now the fileselector box looks like it should! :D

Best regards,
Martin

P.S. @jan-jaap: cigar now? ;)

Image
jan-jaap wrote:
Martin Steen wrote:
P.S. @jan-jaap: cigar now? ;)
Attachment:
cigar.jpg


LOL, thank you, now that' s a nice cigar! Unfortunately I have quit smoking last year, but for
this virtual cigar I make an exception ;)

Best regards,
Martin
Hello,

here is a little program that can be used as a benchmark in a multiprocessor environment.
It calculates three beautiful (?) fractal images:

http://www.martin-steen.de/sgi/frbatch.tar.gz

It makes heavy use of posix threads, so the programs benefits a lot of systems
with more than one CPU. Actually, it is a multithreaded floating-point benchmark.

Atfer unpacking, run the script "./run1.sh" to run a fast benchmark. "./run2.sh" runs a
slower benchmark that creates bigger images. The script uses four threads,
but you can adjust the scripts to use more threads or create even larger images
(8000x8000 pixel are no problem, but it takes a while).

When the benchmark has run, another small program converts the images from Targa
format to Jpeg. The programs are compiled for 64 bit machines (-64 -mips4).

On a SGI Fuel, the first script takes about 120 seconds.
fract_0088_8.jpg
fract_0088_8.jpg (48.88 KiB) Viewed 4944 times

Best regards,
Martin
legalize wrote: The executable in there is a MIPS/IRIX executable?


Yes, the files "fractbatch" and "tga2jpeg" are 64-bit mips executables.

--
My collection so far ;)

:Fuel: :Octane:
Geoman wrote: ~159seconds on a dual R12K400 Octane.

concerning CPU-load, top gave me:

Code: Select all

2 CPUs: 47,6% idle, 51,6% usr,  0,8% ker,  0,0% wait,  0,0% xbrk,  0,0% intr
PID       PGRP USERNAME PRI  SIZE   RES STATE    TIME WCPU% CPU% COMMAND
1399       1398 robert   +20 5472K 2864K run/1    0:27 96,3 96,23 fractba



Hmmm.. looks like only one CPU is working. Unfortunately, I don't own a SGI with more than
one CPU. On my Linux computer with a phenom quadcore, all four cores are 96% busy
(using the same sourcecode).

So, since you have a dual-CPU Octane2, you have to be my betatester now ;)

Thank you for testing and best regards,
Martin
Geoman wrote: Wait! :-)

Seems like Octane has to warmup ^_^ a little bit.
doing the 2nd script, your renderer uses both cpu's in stage 3:

Code: Select all

2 CPUs:  1,3% idle, 94,8% usr,  3,3% ker,  0,1% wait,  0,0% xbrk,  0,5% intr
PID       PGRP USERNAME PRI  SIZE   RES STATE    TIME WCPU% CPU% COMMAND
1402       1401 robert   +20 5696K 3088K run/0  116:09  154 160,1 fractba


Thank you for the report. Seems like there is still an issue about threads that I have
to spot.

Best regards, Martin
ShadeOfBlue wrote: I can give it a try on my 16CPU Origin tomorrow (hope the rainy weather continues :) ).

Also, on MIPS (and other properly designed architectures), 64-bit apps actually run *slower* than 32-bit ones, so compile for 64-bit only if your app uses more than 2GB of memory.


That would be great! I can also give you the sourcecode so you can compile your own
version (MIPSpro compiler needed).

Best regards,
Martin
joerg wrote:
ShadeOfBlue wrote: I can give it a try on my 16CPU Origin tomorrow (hope the rainy weather continues :) )...


You have a watercooled origin? :P

SCNR,
Joerg


Hello Joerg, hello ShadeOfBlue, hello Geoman,

if you dare to run the app on your multiprozessor machines, here is the sourcecode for the
fractal batch programm:
http://www.martin-steen.de/sgi/fractbatch-source.tar.gz

Just type "make" to build the executable.
Run ./testrun.sh to create three (simple) fractals

This test is not a real challange for a machine with 16 cpus.
To make it more interesting, you can try:

Code: Select all

./fractbatch 8192 8192 1024 32 frects0089.txt


This creates the three images with a size of 8192x8192 pixels
and uses 32 threads.

Remarks:
- The limit for Targa pictures is 32768x32768 Pixels.
- maybe you know compiler switches for a faster executable

Best regards,
Martin
Geoman wrote:
Thanks for sharing the sourcecode. It built on MIPSpro 7.4.4m without any error or warning.

Now I'm torturing the Octane with it:
Code:
/fractbatch 8192 8192 1024 32 frects0089.txt


I get 187,8 CPU% right at the beginning.


Ok, then everything seems to work fine! :)

There are two strange warnings I turned off (-woff). They have something to do with
the STL ("A template was detected during header processing"). I don't know what it is
and G++ doesn't show this warning, so I switched it off.

Thanks for testing and best regards,
Martin
ShadeOfBlue wrote:
The "testrun.sh" consistently uses only one CPU, the time used for that test is about 82 seconds (on a 16P 400MHz O3k, compiled with the defaults [and MIPSpro 7.4.4]: "-DEFAULT:abi=n32:isa=mips4:proc=r12k" and the "-O2" from the Makefile).

The other command uses about 10-12 CPUs and is still running :)

When it finishes, I will try to get the first test to run on all CPUs (will probably require setting the number of threads to 64 or somesuch).


Thank you for starting your huge machine for this test!

It looks like IRIX does not start all CPUs when a thread is running to short.

After starting, every worker-thread calculates exactly four lines. The supervisor-thread
waits for all worker threads to stop (*) . Then the supervisor-thread writes the lines to the
TGA-file and starts the threads again to compute the next four lines.

This process makes it possible to render pictures of nearly arbitrary size (without consuming
much RAM).

Quote:
The program dumps core at 40+ threads


Probably this has something to do with the number of lines. Maybe the picture is to small for
so many threads. I will check the source.

Thank you for your report!

Best regards,
Martin

*) The worker-thread does't really stop, but waits (pthread_cond_wait) for the next start signal
ShadeOfBlue wrote:
Martin Steen wrote:
It looks like IRIX does not start all CPUs when a thread is running to short.

You could try forcing each thread to its own CPU with pthread_setrunon_np() .



Good idea. Thank you!

Best regards,
Martin
Hello,

I made a little tool to create thumbnails of JPEG-Pictures (mainly for my own use).
The tool called "Thumbo" creates thumbnails of all pictures in a folder and creates
also a file "index.html", so you can browse the folder with an internet-browser.

http://www.sgi.faktor0.de/thumbo

Change requests are welcome.

Best regards, Martin
Hi!

There is a new version of "Die Planeten".

http://www.martin-steen.de/dieplaneten/ ... sgi.tar.gz

New in Version 1.3:

- Displays the whole solar system with the sun
- Orbits of the moons and planets are shown
- "-lame" commandline switch for machines without hardware-OpenGL

(testet on SGI-Fuel/V10)

Best regards, Martin
hamei wrote:
Martin Steen wrote: Hi!
There is a new version of "Die Planeten".

Martin, this program is phenomenal. Fullscreen with the Earth blown up big it's my new screensaver.

For the next version, could you make the information and control windows separable ? If it were just the planet on a black background it would be absolutely perfect. Maybe make the background even blacker, if that's possible.

I could sit and watch this thing for hours .. but where's the ice caps ? You could drive a freighter from Shanghai to New York over the north pole right now ...

thank you, a lot


Thank you hamei! :-)

You are right, the earth looks different from space. That's why I'm going to replace the earth-map with the "blue marble"-texture.

BTW: there are indeed plans to route ships from Europa to Asia via the so called "Northwest passage".
http://en.wikipedia.org/wiki/Northwest_Passage

Best regards, Martin

EDIT: you can shift the interface by hitting the SPACE bar.
To see the "blue marble" texture as in the attachment, just replace
the file
planeten/erde.jpg
with this file:
http://www.martin-steen.de/dieplaneten/ ... e/erde.jpg
nuts wrote: it doesn't work for me

Code: Select all

./dieplaneten-sgi
GLUT: Fatal Error in dieplaneten-sgi: visual with necessary capabilities not found.


What machine do you have?
nuts wrote: Octane with IRIX 6.5.30f.

Code: Select all

0x28 24 tc  . 32  . r  .  .  8  8  8  8  .  .  . 16 16 16 16  . .


I use a custom resolution (1680x1050) with 24bits colors.



Hmm. Maybe there is no doublebuffering in 24-bit-colormode.

Do other OpenGL programs run (e.G. the "cube demo")?
http://www.sgi.faktor0.de/cube.html

-Martin
nuts wrote: It didn't work with my last 1680x1050_60 file, and nor celestia and blender worked. I try 1280x1024_60. it works, but I don't know why, I have blue sun with die-planeten.

I re-create a 1680x1050_60. celestia, blender and die-planeten run, but I have a lot of artfacts and stanges colors.
I'll try the cube



Weird. I must confess that I don't have a clue.
When you press the "e"-key while running the cube-demo,
does that change anything?
("e" switches environment texture mapping)

Maybe one of the expert here has an idea.

-Martin
hamei wrote: Well, that was interesting .... my O2 runs at 1440 x 900 so I thought I'd give it a shot from home. Found out I didn't have glut installed so got that. Gave the executable a double-click and wham ! computer locked up tighter than a Shanghai Princess' pocketbook. Not the desktop, the entire thing. Vulcan death grip failed, power button failed, I had to pull its life support cord. Sumbitch.

Got it back running again, since Mom is a Republican I guess stupidity is inherited. I gave it another try, this time from a terminal. Wham ! locked up instantly again. I was hoping that just that app would freeze and I could close the terminal window but no such luck. Same thing, nothing did nothin', had to cut off her vital bodily fluids to shut down. Damn commies are everywhere.

This is an r5k-350 O2 running 6.5.22, graphics is 1440 x 900, neko glut (the latest one, forget what rev.)


I'm very sorry to hear that! (although your description made me laugh, sorry again!)

It seems like there is still lots of work to do.
Hope I get the Octane 1 running, so there is a
second system for testing.

Thank you and thanks to nuts and all other users for testing and for the reports, I will update this thread
when there is a new version.

Best regards,
Martin
canavan wrote:
hamei wrote: [...]Gave the executable a double-click and wham ! computer locked up tighter than a Shanghai Princess' pocketbook. Not the desktop, the entire thing. Vulcan death grip failed, power button failed, I had to pull its life support cord. Sumbitch.
[...]
This is an r5k-350 O2 running 6.5.22, graphics is 1440 x 900, neko glut (the latest one, forget what rev.)
Same lockup here with another O2 r5k-350. Tried two different default visuals because it's working fine on my O2 R12k-400. While one did show me a false-color window frame of Die Planeten and the other showed nothing at all, both resulted in a lock up.

Martin, could you please link the next version with "-rpath /usr/nekoware/lib" (or "-Wl,-rpath -Wl,/usr/nekoware/lib" depending on how you invoke the linker)?


Could you do a test with a demo program?
Here is the sourcecode:
http://www.martin-steen.de/sgi/chromawa ... rce.tar.gz
It contains a simple makefile. This program is much smaller than "Die Planeten".

(Below is a screenshot of the chromawave demo)

Best regards, Martin
Hello,

here is another little interactive OpenGL demo.
http://www.sgi.faktor0.de/chromawaves.tar.gz

Hit the space bar to create colorfull waves.
Move and zoom the field with the mouse.


Sourcecode with makefile for MipsPro-Compiler:
http://www.sgi.faktor0.de/chromawaves-source.tar.gz

This demo has more error-checking code than my other
programs, but, als always, start at your own risk .

Required libraries: GLUT library
http://de.mirror.nekoware.net/current/n ... 25.tardist

EDIT: Youtube video
http://www.youtube.com/watch?v=XnOzAVC7WZg

-Martin
hamei wrote: Works nicely on the Fuel, V12 6.5.30 neko_glut. I'll try it on the O2 later.

I wonder if you could reverse the action of the scroll button ? It's backwards from the way zoom works on any other apps I have ...

You know what would be useless but neat ? Pipe the output from sound to act as input. i always liked that rotating drum equalizer demo thing. This is even spiffier.

thank you.


Thank you for testing, hamei!
I take your tipps and suggestions into consideration.

Best regards,
Martin

P.S. I had to look up in an dictionary if "spiffier" means good or
bad, but I learned it means good :D
nekonoko wrote:
ShadeOfBlue wrote: I vaguely remember reading something about floating-point bugs in the 350MHz CPU's, which made them unsuitable for e.g. Maya. Since the O2 uses the main CPU for geometry transformations, it could be triggered by an OpenGL app.


Right, that's why SGI recalled the RM7K/350MHz CPUs. Kind of interesting to see it pop up now though, and equally interesting that the faster RM7Ks aren't affected.

Edit: A little more info here: http://groups.google.com/group/comp.sys ... fecdf3e025

Looks like it was a RM7000A problem. The 600MHz hobbyist upgrades use the RM7000C.


Both apps (Die Planeten, Chromawaves) make heavy use of trigonometric functions like sin() and cos().
I have sent hamei a test version of the demo program to proof it's not a software glitch. I' m still not sure
if it's a hardware bug. 99.999% of all bugs are software related (that's my experience, at least).

Best regards,
Martin

P.S. thank you very much for reporting about my programs on the start page!
Bill622 wrote: Any chance to have an executable version for my O2?

Code: Select all

# ./fractbatch: Exec format error. Wrong Architecture.
# file fractbatch
fractbatch:     ELF 64-bit MSB mips-4 dynamic executable (not stripped) MIPS - version 1
#

I'm just curious...

:)


Is the O2 not a 64-bit-machine?
It's 10 years ago that I worked on a O2.

Here is another executable for you, compiled with compiler-switches -n32 -mips3:
http://www.martin-steen.de/sgi/n32/fractbatch.gz

Best regards,
Martin
bplaa.yai wrote: Thanks for the nice toy Martin !
Just tested it on the Onyx2 IR2E and the Onyx IP, works great on both. Just a note : it looks a bit dark (eg. I don't see anything until I hit space), I'm not sure if it's related to my gamma settings (I use gamma 1.0 on my sgis)...


Run "./chromawaves -auto" if you want the see waves from the beginning.
ShadeOfBlue wrote:
Martin Steen wrote: Is the O2 not a 64-bit-machine?

It has a 32-bit kernel, since there's really no reason to run it in 64-bit mode due to the 1GB memory limit (it can, however, still use 64-bit instructions -- it just lacks the kernel support and libraries that use a 64-bit address space).

It is more efficient to run MIPS4 N32 code on all SGI machines that have an R5k or better CPU inside (and MIPS3 N32 for R4k). Compile it as 64-bit only if your app uses more than 2GB of memory, otherwise it will just cause a slow down and use more memory.


So the O2 has a 64-bit CPU, but it cannot run 64-bit code because the kernel and the libraries are
32-bit? That's good to know, if one is going to use posix memory mapping (mmap) with big files.
(on my job I have to deal with satellite images that can be 200GB large).

Best regards, Martin