SGI: Computer Graphics

MattPayne wrote: ok... it looks as though i havent installed it properly on my O2 - when i click on the ......./bin/wings icon, nothing happens...

generally speaking - not always, mind you, just usually - if you're having a problem you'll get better results by using a terminal and typing the executable's name at the command line. Sometimes you'll need to enter < ./binary's-name > to get it to run. Usually this will give you some feedback on exactly what is failing. If it has to be run as root (cdrecord, for example) then don't forget to < su > first.

dexter: that sounds definitely promising, looking forward to the results.
one thing though: in case you're able to fix the issues and provide a binary, i hope it's not too much to ask to make it compatible with IRIX'es below the .20's.

anyway i hope your efforts will pay off.

hamei wrote:

MattPayne wrote: ok... it looks as though i havent installed it properly on my O2 - when i click on the ......./bin/wings icon, nothing happens...

generally speaking - not always, mind you, just usually - if you're having a problem you'll get better results by using a terminal and typing the executable's name at the command line. Sometimes you'll need to enter < ./binary's-name > to get it to run. Usually this will give you some feedback on exactly what is failing. If it has to be run as root (cdrecord, for example) then don't forget to < su > first.

I think RTFM sums up my newbiness once id put the decompressed folder into the right place and used the command line (thanks hamei) the program is running...

now off to find some tutorials....

Running some tests on the esdl extension revealed some odd behaviour (from esdl Readme):
wow, that was quick! Only the second one works fine (a spinning colored cube):
That segmentation fault is also typical when quitting wings on my machines.

I have a distinct feeling that this crapping out of SDL is due to esdl having -lpthread, because neko_sdl has -lpthread as well, but erlang is compiled without threading. Trying to turn on threading breaks compile with a malfunctioning 'beam' executable:
... while a non-threaded 'beam' does this (a normal crash report):
This merits some investigatoin why the erlang --enable-threads produces wrong code...

Oh, and i indeed have no icons on my impact system, but they appear on the O2 just fine...

after the failures I suffered on my own indy... I took the same erlang/esdl/wings tar.bz2 I used there and freeware SDL and went to an octane... just to test stuff. It has ESI graphics.

tere both testgl and testsprite seem to work (this makes me think that tomorrow I'll try those tests on my own indy). And exit without segfault.

FUrthermore on the octane I can almost run wings. It starts and I see no particular artifacts in the interface. I see the icons, the axes, the menus... the menus seem to work, I can add a cube for example (so the pop-up menu works) and I can spin the camera. I can select faces.
But some opration make everything hang. For example, with a face selected, I select "inset" from the pop-up menu and every thing hangs, no mouse cursor anymore. But I see that the apps in the background continue to work.
SO instead of killing X, I telnet remotely kill the beam... and tada my desktop is there again.
So the bugs are there and are subtle.

after the "success" of running the esdl tests that dexter run on the octane, I tried again on my indy.

I still use the stuff compiled by jdb.

the testsprite test is ok, the testgl not:

olorin 13% /opt/jdb/erlang/bin/erl -pa ../ebin
Erlang (BEAM) emulator version 5.3 [source] [threads:0]

Eshell V5.3 (abort with ^G)
1> testgl:go().
Command:68:SDL_GL_SetAttributeFunc: ok
Command:35:SDL_ListModesFunc: ok
Command:31:SDL_VideoDriverNameFunc: ok
Driver "x11"
Available WindowSizes [{sdl_rect,0,0,1280,1024}]
Command:34:SDL_VideoModeOKFunc: ok
Command:34:SDL_VideoModeOKFunc: ok
Command:34:SDL_VideoModeOKFunc: ok
Command:34:SDL_VideoModeOKFunc: ok
A guess at max video res is 1280x1024:32
Command:36:SDL_SetVideoModeFunc: ok
Command:69:SDL_GL_GetAttributeFunc: Segmentation fault
olorin 14%


I remember an extremely simialr problem on OpenBSD/sparc with 8bit graphics and Mesa. I wrote to both esdl and sdl teams and eachone said the problem was from the other. Esdl always replies "look at my code, it is jsut a wrapper".
I compiled SDL myself and I could run all their tests fine though

Here the siutation may be a lot different though.

I then tried to run other tests:

4> erldemo:go().
Fatal signal: Segmentation Fault (SDL Parachute Deployed)
olorin 16%

This sounds bad too, doesn´t it?

MattPayne wrote: ok... it looks as though i havent installed it properly on my O2 - when i click on the ......./bin/wings icon, nothing happens...

I decoempressed the file untill i had a folder structure, and then tried running the executable... is there something else i needed to do? and where was the SDL dep found... i looked through the freeware libs but it wasnt in the 's' section.....

I found it in the freeware libs, whatever was current in the summer of 2003. I don't actually check that the dependency was met, as you may have figured.

BTW, you may need to run wings from the command line. I've never tried clicking on the exectuable. If nothing else, you may need to do this to get helpfull error messages.

gandalf wrote: But some opration make everything hang. For example, with a face selected, I select "inset" from the pop-up menu and every thing hangs, no mouse cursor anymore. But I see that the apps in the background continue to work.
SO instead of killing X, I telnet remotely kill the beam... and tada my desktop is there again.
So the bugs are there and are subtle.

So, I guess I should set up sshd on my Octane then for use when working on wings.

Would you please try using a keystroke instead of selecting the popup menu for one of the functions that fails? I don't know that inset is mapped to a keystroke, but I believe that some of the other crashing menu options are, and of course, the keystrokes can be remapped.

dexter1 wrote: I have a distinct feeling that this crapping out of SDL is due to esdl having -lpthread, because neko_sdl has -lpthread as well, but erlang is compiled without threading. Trying to turn on threading breaks compile with a malfunctioning 'beam' executable:

Code: Select all

irene /usr/local/src/otp_src_R10B-2/bin/mips-sgi-irix6.5> beam
Failed to create thread: Operation not permitted (1)
Abort (core dumped)


... while a non-threaded 'beam' does this (a normal crash report):

Code: Select all

mech044 /usr/local/src/otp_src_R10B-2/bin/mips-sgi-irix6.5> beam
{"init terminating in do_boot",'no -root flag'}

Crash dump was written to: erl_crash.dump
init terminating in do_boot (no -root flag)


This merits some investigatoin why the erlang --enable-threads produces wrong code...

Oh, and i indeed have no icons on my impact system, but they appear on the O2 just fine...

OK, I finally have a second terminal (a Mac) set up at home. So, a year later, I'm finally able to put some small amount of time towards this.

First, about the black icons. The icons are being drawn via a textured quad. The textures are GL_RGB, loaded from BMPs. I haven't found if Wings is expanding the textures to a power of two or not, but wouldn't they have to, even on linux? Something sounds familiar about this. Something along the lines of other people porting linux software to Irix having the same sort of issue with texturing. But, I'm having trouble finding references to it on google groups.

Also, I found that the menu operations (lighting, extrusions, and beveling, perhaps more. I lost the comprehensive list I wrote out previously and haven't retested everything) that cause the lock ups will also caused lockups if executed by keystroke rather than menu selection.

When the lock up occurs, the usr CPU load isn't very high, but the sys CPU load is very high. I have wings positioned so that I can see gr_osview, and it keeps updating normally during the trouble. As gandalf points out, remotely killing beam restores the desktop without having to log out and back in. Based on the CPU information, I think that the only reason things seem locked up is perhaps because wings always does wierd things to the mouse pointer during operations, and thus nothing is really locked except wings but you can't use the pointer to change window focus. That may be a crappy theory.

Anyway, I'm in the middle of rebuilding the latest OTP, Esdl, and Wings (OTP and ESDL are built, but I haven't run the esdl tests or built wings) as of this morning. I now can read erlang code enough to figure out what is where, but I still don't really know erlang, and I especially don't know how to use the debugger.

Dexter1, do you think it would be possible to build SDL and esdl without pthreads? I'm digging around to look into that. If not, I may join some erlang mailing list and try asking about why --enable-threads won't work.

Thats what you get when you write a 3D graphics app in a language meant to program telco switches.

Thats like writing Photoshop in FORTRAN.

I looked into porting Wings myself, before I knew you were doing it. And when I found out it was written in erlang, and not C or C++, I said screw it.

You're a braver man than I, just wanted to let you know that there is at least 1 person out here rooting for you to get this thing usable. Keep up the good work!

mikesapunk wrote: Thats what you get when you write a 3D graphics app in a language meant to program telco switches.

Thats like writing Photoshop in FORTRAN.

Photoshop in FORTRAN. Hmm. Something familiar about that thought.

Photoshop in FORTRAN.

Photoshop in FORTRAN.

Wait, your talking about Avid/Parallax's Matador, aren't you?

mikesapunk wrote: I looked into porting Wings myself, before I knew you were doing it. And when I found out it was written in erlang, and not C or C++, I said screw it.

You're a braver man than I, just wanted to let you know that there is at least 1 person out here rooting for you to get this thing usable. Keep up the good work!

Erlang mostly works and a lot of wings works as well. It has got to be something small somewhere I think.

mikesapunk wrote: Thats like writing Photoshop in FORTRAN.

Oh goody. Language War !

All the original 3D graphics apps were written in FORTRAN. There were computer-aided design programs long before anyone was playing with animation or graphics for movies. APT actually predates FORTRAN - it's a fully 3D language and program that both describes 3D objects in space then moves a tool in a controlled path within that space. APT was the very first ANSI standard computer language. Fortran was the next. APT was rewritten in FORTRAN in around 1970 .... Much of the early graphical stuff was done in Fortran. Ever hear of Unigraphics ? The one that started life as UniAPT ? Fortran is okay. PhotoSnot is a very late-comer to the graphics scene.

p.s. Much of your financial institutions are still running on COBOL. And the airline reservation systems are still using COBOL or even stranger, more orphaned languages. There's nothing wrong with an old language once you get past the first six columns on the punch cards

hamei wrote: Oh goody. Language War ! :)

Been too long since the last one.

hamei wrote: There's nothing wrong with an old language once you get past the first six columns on the punch cards 8)

Of course, they still haven't managed to make a language better than the third language to be available, Lisp (early 50s).

dexter1 wrote: I have a distinct feeling that this crapping out of SDL is due to esdl having -lpthread, because neko_sdl has -lpthread as well, but erlang is compiled without threading. Trying to turn on threading breaks compile with a malfunctioning 'beam' executable:

Code: Select all

irene /usr/local/src/otp_src_R10B-2/bin/mips-sgi-irix6.5> beam
Failed to create thread: Operation not permitted (1)
Abort (core dumped)


... while a non-threaded 'beam' does this (a normal crash report):

Code: Select all

mech044 /usr/local/src/otp_src_R10B-2/bin/mips-sgi-irix6.5> beam
{"init terminating in do_boot",'no -root flag'}

Crash dump was written to: erl_crash.dump
init terminating in do_boot (no -root flag)


This merits some investigatoin why the erlang --enable-threads produces wrong code...

I'm not getting the same results. I built erlang with --enable-threads, and when I run beam, I get the crash dump message rather than the Abort (core dumped) message. However, I didn't do a gmake clean first, so maybe I got stale files. Launching them again.

I'm attempting to join the erlang mailing lists. I wish the wings people would use mailing lists rather than that dratted web board.

Also, none of the esdl tests work on my new build of erlang and esdl. I'm using a Summer 2004 freeware SDL.

I'd be happy to having wings use it's own build of SDL (maybe even statically link) if that's what it would take to make it work.

dexter1 wrote: Oh, and i indeed have no icons on my impact system, but they appear on the O2 just fine...

BTW, running Wings on linux with the DISPLAY directed to Impact graphics has the same issue.

Hello. A bit late, yes, but I'm trying to clarify the current 'official' status of Wings 3D on IRIX 6.5. After a maybe-too-quick search in the forums I'm still not sure if anyone managed to get it running fine. That is, no crashes, no lock-ups, good-looking icons, etc.
I solved all these issues on my own, maybe someone would like to know...
Thanks in advance.
-Daniel

dsolaz wrote: Hello. A bit late, yes, but I'm trying to clarify the current 'official' status of Wings 3D on IRIX 6.5. After a maybe-too-quick search in the forums I'm still not sure if anyone managed to get it running fine. That is, no crashes, no lock-ups, good-looking icons, etc.
I solved all these issues on my own, maybe someone would like to know...
Thanks in advance.
-Daniel

Someone should probably take a stab at it again. There was recently some activity on the erlang mailing list about getting it up on Irix again.

For a quick recap, the first try built something that would run, but often locked the machine up. The second try wouldn't build.

Hello, and sorry for not being clear (English is not my mother tongue).
I am the guy who patched Erlang (well, just the os_mon utility, actually, but I also found the solution to the pthreads problem, which is not a bug) to run on IRIX. I did solve all Wings 3D issues, at least those present on my machines, an O2 and an Octane/SSE. I have it working *almost* flawlessly on 6.5.26 in both 32- and 64-bit multithreaded mode.
I'd like to know if it's worth creating a tardist or there is already one that can be considered "nekoware-official". If it is worth doing it, I would need assistance with the software packager.
Regards.
-Daniel

If you can provide a patch or instruction what is needed to compile erlang with mips pro i will try it and create an nekoware package. Last time erlang doesnt compile.



This was otp_src_R11B-1.

regards
Joerg

Gcc is *required* in order to compile Erlang. IIRC this is stated in the README. I have used gcc 3.3.something.
I will collect my configuration notes regarding Erlang, ESDL and Wings 3D when I get home, and post them here tomorrow. Getting Erlang and ESDL running is not hard, Wings 3D took a bit of trial and error.
Regards.
-Daniel

Can't be included into nekoware due to gcc, but a working tardist would be greatly appreciated.

/KRM