The collected works of jdboyd - Page 1

OK, I've packaged the stuff more sanely, upgraded to a new version of
wings, and put together a web page about it. See:
http://jdboyd.net/wings/
and let me know if I left out anything important.

Sorry, tar.bz2s rather than tardists.

There are two known bugs specific to the Irix version. They are mentioned on that web page. One of them is a major pain when it happens, but the other isn't that big of a deal.
you might check if the wings team (specifically dan) knows anything about what might cause the crashes.


I'm going to have to try emailing them. The wings message board refuses to let me post. I've been trying.

Anyway, I did a lot last night trying to work on this crashing bug. I've realized two things. It is a much worse bug than I suspected, but it is so far completely repeatable.

It mostly effects operations on faces. For the most part, operations on vertexs, edges, and objects work fine. I haven't finished trying everything, but I've tried most things. A write-up of what does and doesn't crash it will be posted to my website ( http://www.jdboyd.net/wings/ ) later today. I haven't finished testing every operation, and I especially haven't tested yet whether an operation that locks it up when selected from a menu also locks it up when called via a hotkey.

In the mean time, the operations that crash it can be worked around, but doing so is slow and annoying. For instant, extrude face of all types consistantly locks up wings and the desk top. Extrude edges works just fine though, and you can then use the vertex on the extruded edges to build the missing face. Despite being able to work around the problems, I would classify Wings on Irix, at this point, as unusable.
yep, i tested wings on my box before reading your reply and boom - it crashed my machine after 5 seconds of actually using it. a simple face inset did the trick.


The short summary of my findings about crashs is that many of the face operations (other than move/scale/rotate) cause crashes, but very few of the other classes of operations cause crashs (but there are a few that do).

BTW, the only bug when one is running wings on linux with the display piped to Irix is the icons. And it doesn't take much of a machine for this to work decently. Any P2 with 128megs of ram, and a decent ethernet card (not the Realteks, but preferably something like 3Com, Intel, or Dec Tulip based, because Realteks eat a lot of CPU power) should be fine for piping the display over. A machine like this should cost you less than $100.

At this point, I'm wondering what happens if I run wings on Irix, but pipe the display over to linux. When I next have time at home I shall have to try this.

A big problem with me working on this is that I mostly use my Octane for real work, and only turn to work on wings as a diversion. If I have to close all of my real work first before spending 20 minutes on wings because of the desktop locking up, it is a major annoyance to have to reopen all the files, emacs windows, shells and other tools. I have a feeling I'm not going to make large amounts of progress on this until I get an additional machine to use for testing.
I am very much unclear on why you can't just use a video distribution amp rather than having multiple O2s playing back the same file in sync.

That said, assuming that you really do need the setup you describe, you shouldn't need very high end machines. Likely as not, base O2 R5000s with 128+ megs of ram would do the trick just fine, especially if you are getting 200mhz ones instead of 180mhz ones. I'm assuming you are planning on using the supported MJPEG codec rather than uncompressed or any other compression. The tricky part is that if your video files aren't pretty short, keeping the O2s in sync will be a problem, since their clocks will probably run slightly different. And, if you are using ethernet to control the slaves, you may also have problems getting them to start in sync. Of course, you mention in sync, but you don't specify exactly how in sync they need to be. If you mean started within a few frames of each other, and they run about the same speed, you are fine. But, if you need them to really be frame synchronized to the same video clock, you are going to either need a much more expensive O2 (one with a pro video option) or another platform, so that you can use genlock.

As to the lighting stuff, DMX 512 is a protocol over RS485. Probably a RS485<->RS232 adapter is good enough to get the signal into your "master" O2, presuming that they don't do anything too strange with the 485. At that point, you need software that understands DMX 512, and you would likely be on your own to write it yourself, but then, that describes pretty much everything you've talked about doing so far.

Now, if the only reason you want to use multiple video servers, rather than a single video source and a distribution amp is so that each projector can have the video signal keystoned corrected for it, well, I think you are probably trying to do things the wrong way (but I don't really know for certain what would be better here), but it might be easier for you to use one video server, then have an O2 at each projector that digitizes a frame, corrects it, then spits it back out. This will pretty much completely remove your sink problems, plus you won't need multiple copies of the video files (one for each machine), etc.
Thank you for the extra information. It makes things much more clear.

To stitch the stuff together, you will get best results if you genlock it. You could use an external frame sync, but they are expensive, though not as expensive as the SDI board for O2s (which I think is what you need to genlock O2s). That said, I'm not really sure how bad it is to do it ungenlocked. People say it is a "very bad" thing, but I haven't seen it for myself. I believe it is a flicker issue. I'd recommend trying it and seeing how bad it is.

Also, to make sure the machines start in sync, I might look into using a variation on a RS485 network between the machines rather than ethernet to make sure they really get the start message at the same time. If you can do your own coding, this really isn't too hard to do. If you can't program, it would be much, much harder to achieve.

A central server that can spit out multiple video signals would make sense (if you had the budget), but now that I understand what you are trying to do better, I doubt it would be cost effective. I don't know of any reasonable way to do it without rather expensive pro hardware (either multiple video out cards, or a multi stream MPEG playback card).

On a side note, I'd love to see a fairly platform neutral DDR program that speaks Sony protocol RS422 or 485 (forget which) and can support multiple file formats on multiple platforms using various types of playback hardware. If such a thing existed, it would make your life simpler, but I don't know of any such program. Maybe I'll write one someday, if I ever find a copy of the spec (I think it would be way cool to write a program where I hook a dual VCR edit controller up to the two serial ports on an O2 or PC, then use the edit controller to do cuts only editing on the machine. I don't know why, I just want to do it).

As to the keystoning thing, you could get custom software written to do it. It is a poor way to do it, but I'm not at all familiar with the sort of projectors your planning on using in November, and I can't think of any better way if the projector lense or CRT (if applicable) doesn't do it. The best I can think of is to make sure to test that your images look good keystoned before the event, and adjust the artwork otherwise.

Good luck. If you have any more questions, feel free to ask. Live events isn't really my area, but a lot of what I know overlaps significantly.
vegac wrote: You mean I'm the only one left who uses vim for web-site design these days? As for graphics, Gimp is decent (at best in my opinion), Photoshop for Irix is old, but still probably better, though you can't get that anymore, so your only hope is to have it just happen to be already installed on a machine you get off of Ebay or what-not.

The vector apps mentioned above (SodiPodi preferably) aren't bad, though I'm not much of an artist so maybe they are and I just don't know it :)


Yes, you are the only one left using Vim. The rest of us have moved up to emacs. :P

Personally, I like Gimp. I think that for most tasks, Gimp 1.4 is as good or better than Photoshop 3. Sure, it doesn't do CMYK, but that isn't relevent to this topic anyway.

As to vector programs, SodiPodi may be usable, but the last time I used it, it was no where near as nice as even corel draw for illustration type stuff. Now that I look at the web site though, I'm realizing I haven't used it in a very long time, so perhaps I should keep my mouth shut.

For more technical vector drawing, there are a lot of nice free tools depending on what you want. I've used Dia for a few things. I've used Xfig for a few things. Both are pretty god.
hamei wrote: You could always use Illustrator. It has an okay reputation ... :-)


Oh, does that mean they've started issueing licenses for Illustrator on Irix again? Very cool! Even if it is only version 5.5 (which I think is one of the better versions anyway).
Diego wrote: Dia is my way. I can't imagine currently a vector graphics drawing program more easy to handle. I use every single day to arrange my programming diagrams before coding. Wonderful little piece of technology!


When I want diagrams for programming (say, state machines, object models, etc), I use a program from AT&T (opensource, not that hard to get onto Irix) called vizgraph. It does a nice job of putting out graphs from a simple text file format. I usually have it spit out postscript files for printing or conversion to PDFs, however, for graphs complex enough to give it some trouble it will spit out Dia files that can then be tweaked in Dia.

The thing that I really love about vizgraph is that I like to use code generators for various tasks, like state machines. So, I modify the code generator to spit out both C code for the state machine, but also the vizgraph file for the state machine. That way I don't have to worry about there being differences between the printed graphical representation and the C code. I think it's a very powerful way of working.

Of course, this is now starting to trail a bit off topic, unless the original poster is really interested in web sites for programming documentation.
Sparrowhawk wrote: Does anyone have a link for vizgraph? I tried google and looking around some of AT&T's research sites but didn't find anything overly useful.


Sorry dude, I got the name backwards. It's really graphviz.

http://www.research.att.com/sw/tools/graphviz/

/me looks sheepish.
loonvf wrote: If only we had a professional programmer that could write some code....


I was under the impression that we had several of those. It's just a matter of finding ones with free time, and getting the right hardware into their hands.
gandalf wrote: That is the first bunch of ideas. Porting my image filtering program to IRIX would be nice too, but it is quite tied at the moment to the Objetive-C/OpenStep architecture.


I just don't like Motif that much, so excuse me if I don't leap forward to work on this project.

Anyway, in what ways is your image filtering stuff tied? I believe that GCC's Objective C support works fine on Irix. So, if you were to port the GNUstep backend over you would probably only have to redo any GUI code to use Motif instead of the NextStep GUI libraries.

As to your project in general, what's wrong with FLTK? Being based somewhat on FORMS, to my understanding, it seems that using FLTK on Irix is about as true to the spirit of SGI's heyday as Motif is.

I also wonder about the posibility of going back and using FORMS. It is based on IrisGL, which I find particularly appealing.

Recently, I've been having a strong desire to go back to a Crimson like machine, or early Onyx, running 4.0.5 or 5.3, and writing IrisGL code for my projects instead of OpenGL/SDL/FLTK code (don't ask why I'm bothering to use SDL. It has to do with not yet figuring out how to do everything in FLTK).
gandalf wrote: FORMS is the toolkit with which Jot, showcase and other programs are written? I like its menus (in the 6.5 version at least, the 4.0 they are a bit crude) and the design of the widgets. But SGI itself touts it as "obsolete toolkit". I never programmed it. Also I don't think it is cross-platform.

The advantage of Motif is that it would work smoothly on other Unices too and even on *BSD or Linux with OpenMotif or even better Lessitf.


After mouthing off about FORMS, I figured I better go look up some information about it. I already knew it was based on IrisGL, and as such was somewhat of a dead end. I always figured that Jot and Showcase were now motif apps. I believe that Showcase was formerly forms based though.

Anyway, if one wants to write software that will run on Onyx4s, FORMS is certainly not the way to go. However, there is also XFORMS. It is like FORMS (I think it is partially compatible, but I'm not sure), but it uses X11. Where FORMS would let you drop down to writing native IrisGL code, XFORMS lets you drop down to X11 or OpenGL.

Both FORMS and XFORMS have the source available. FORMS may be a bit of a dead end because of it's dependence on IrisGL, but XFORMS has no such limitation, and should work on everything from MacOS X to Linux.

Now, what I would like to see is people really writing software for older SGIs. Some porting is allowed and encouraged (why use old jpeg and tiff libraries?), but I'd like to see stuff written to run on Irix 4 (and later) and using IrisGL instead of X11/OpenGL. Yes, call me crazy, but that's what I want. Of course, I'm not exactly backing it up with actions. For one thing, nothing I have is running anything older than 6.5.20 yet.

I also wish that more old software could be found. Like, Flame 3.9.10 comes to mind as something that would be very nice to have (I think that was the last IrisGL version, and I think it would run on a Crimson VGXT with Wacom tablet). Software from Alias and Wavefront prior to the merger would also be extremely cool.

Alas, when I have seen old stuff, I haven't been able to afford to buy it (I say a flame 4 on Onyx once, but it still went for over 15 grand).
gandalf wrote: http://world.std.com/~xforms/

I found xforms here, but the stuff seems me little updated and also. And I found no references to the SGI toolkit and the compatibility. I wonder also if sgi provides libraries for it in irix4 and irix 6.5 ... look if you fid something suitable in /usr/include I found the runtimes in /usr/lib but they may be for compatibility only

(the excellent imageworks is forms based too)


How often a thing is updated is only relevent if it lacks features that you are hoping someone else will add for you. If it does what you need, who cares if it gets updated?

As to compatibility, I think it comes in the form of the API being similar, and being able to load FORMS layout files. XForms isn't SGI specific (unlike FORMS, which was pretty much SGI specific, although I heard rumors of a AIX port), but I know people used it. But, that doesn't mean that SGI ever used it internally (which I think that did do with the original FORMS). Still, if you can still compile it, again, who cares how much SGI did with it.
Cory5412 wrote: Framemaker is available on Solaris? I wouldn't have known that. How odd, especially since the discontinued the Mac version. (Along with the Mac version of Premeire, and along with putting less emphasis on Acrobat for OSX (wonderful-wonderful screen-PDF)


I suspect that DisplayPDF and FCP really pissed off Adobe.
hamei wrote: Premiere is nothing special


Premiere Pro has some audio features we needed that other cheap windows programs didn't. Now if only I could remeber what they were. It had something to do with

hamei wrote: Photoshop is no better than GIMP, the interface is straggly and a mess to use and it also hasn't really been updated in ten years. It also crashes frequently. On a Windows peecee, their main emphasis.


The Gimp doesn't really do CMYK, which is important to some people. I think that it still doesn't do 16bit, even in 2.0, but I'm not positive. Of course, Cinepaint fixes the latter problem.

Personally, I'm not so thrilled with recent Gimp developments (nor with photoshop these past few years). I tend to use Gimp 1.2, but am generally moving to cinepaint.

hamei wrote: Illustrator has the same klugey interface that was fine in 1987 but really, c'mon now, all they did in the latest version was replace the old background graphics with some slightly nicer ones then called it a new version. Otherwise I can't see any differences and it STILL takes about a half hour to load. So does P-Shop, btw.


I have Illustrator. Freehand was much better. And Coral Draw was at least easier. I think the whole field has been stagnating though.

hamei wrote: So all in all, imo Adobe is a pile of shit.


Indeed.

Though, I note that you didn't mention anything about AE.
Cory5412 wrote: Even so, people still keep a copy of word kicking around because it's what 90% of the computing world uses :P


I don't keep a copy of Word around. Word in fact came with a Mac I bought (Quadra 660AV), and I made a point of tossing it, just so that people couldn't acuse me of keeping Word around. I don't even have Word where I work.

So far I haven't been sent any Word files that OpenOffice couldn't read correctly, and I do get sent Word files pretty frequently at work.
Dubhthach wrote: Unfortunaly there are "Irish Pubs" all over the place they give about as much insight into a proper irish pub as a McDonalds in Rome would about traditional american roadside Diners (if such things still exist lol)


There is at least one proper road side diner where I live. There is a second one that could be counted I guess, but I think of road sides as being non urban, and the second one is urban. On the other hand, I think that the town expanded out to it, rather than it actually being built in town.

The first attracts a lot of hard core trucker types. The second is more family oriented.

Both serve excellent food.
I'd like to see Wings3D ported properly. Some time ago I build it on Irix, but it locks up the window manager or Xsgi or something of that sort when running on Impact graphics. It might do it on other graphics, but so far it has only been tested on impact.

BTW, running the program on a linux machine with the display redirected to the Octane works fine.
MattPayne wrote: :) ive just downloaded this to play with on my O2...

has any progress been made with the randon locking up??? :)


So are you saying it effects O2 as well? I didn't have my O2 yet when I last had time to work on it.

Oh, and for me it wasn't random. It was always specific menu items that caused trouble. I don't recall if using keystrokes for those actions instead of the menus helped. I've documented the functionalities that trigger the problem here: http://jdboyd.net/wings/bug.html

The big problem for me working on this is that I don't know erlang, and I'm not a major Irix expert. Since I last worked on it, I've picked up a little (very small) amount of erlang. Hopefully enough to be able to start instrumenting the code near the actions that cause trouble. I've also learned about a tool called Ogldebug.

Moving on from here, I think the first step would be to see if the keystrokes prevent crashing. The second step might be to use ogldebug to see if it finds any errors. I figure that most likely only an OpenGL or X11 related bug would cause the machine to misbehave in the way it does. Someone should verify that.

To be clear, I'm still interested in getting this fixed up. However, I still don't have the time to devote to it. I'm hoping that in the near future, I will have a spare machine set up to dedicate to working on wings, which would help (by not requiring me to have to repeatedly reset my main workstation that I tend to keep other work open on).

Also, at this point, it may be wisest to build the latest version of erlang and the latest version of wings. Hopefully the latest erlang will still be easy to build on Irix.

If other people want to work on it, I have the time to coordinate, but not much more. Work has me in major crunch mode from now until likely May.
MattPayne wrote: ive not been able to install it yet... I untared the archive and the executable wouldnt work for me... i forget the error that came up, but ill have another look tomorrow - tbh im not sure if i installed it properly, im not used to installing without swmgr... :(


Find what the error is and post what version of Irix you are using. I built it on Irix 6.5.20f with a SGI Freeware (don't recall version, but can look it up) GCC. This probably means you need to install the GCC libraries from SGI Freeware.

I know others have had no trouble installing it. Of course, they still ran into trouble using it.

All this interest might motivate me to return to this project.
dexter1 wrote: I've finished my build of erlang, the erl-sdl interface and wings yesterday with freeware-gcc, and will try it out today on my O2.

There are some funny gnu-isms in the erlang makefiles (read: they are non-POSIX) and building ssl and java interfaces took some time to get it right.

Let's see what will work...


Java and SSL? Those are erlang features not needed by Wings, right? I think I skipped them previously.
gandalf wrote: If I try to run wings on my Indy with XZ (X set to truecolor) eshell aborts saying there are no opengl drivers and no suitable opengl modes were found...

Dump written 2005-1-15_23-52
Window: "<Unknown Window Name>"
Crashed in:
{"No suitable OpenGL mode found (are OpenGL drivers installed?)",
[{wings_init,video_mode_failure,0},{wings_init,init,0},{wings,init,1}]}

but...

olorin 10% /usr/gfx/gfxinfo
Graphics board 0 is "GR2" graphics.
Managed (":0.0") 1280x1024
4 GEs, 1 RE, 24 bitplanes, 4 auxplanes, 4 cidplanes, Z-buffer
GR2 revision 4, VB2.0
HQ2.1 rev A, GE7 rev B, RE3.1 rev A, VC1 rev B, MC rev C
unknown, assuming 19" monitor


OK. First, what version of Irix are you running? I used 6.5.20f, and I am by far not an expert on how to make sure it will run on any 6.5.

Second, would you mind posting your glxinfo?

Otherwise, I'll have to add that to the list of things to look into. I have an Indy XZ, and Indigo2 with some pre-Extreme graphics at home, so I'll have to set them up at some point.

I would really like to see wings working on any machine that can run 6.5 if possible for a reasonable amount of work. It is such a cool program, and to me it recalls the SGI heyday, even if it is a fairly new program.
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.
unixmuseum wrote:
Yes they are... 32-bit Linux needs a recompile of the kernel to address more than 800MB, but it works a little better than on Windows...


I've seen other people say that as well. Yet, I have three linux machines here, one with 1 gig, and 2 with 2 gigs, and I don't recall doing anything to make them see and use the entire ram. One of the machines is using a stock RHEL 3 kernel, one is using the stock RH9 kernel (because I haven't changed it yet), and one is running a custom compiled kernel with the bigphysarea patch (but I don't recall doing anything fancy in the configuration).

Is the real issue that a single application can't use more than 800 megs? Even still, on the RHEL box I've run a program that used 900 megs.

unixmuseum wrote:
What's not running at all or not very well on Linux are the major pre/post processors... Patran runs like shite on Linux, FEMAP and I-DEAS don't run at all. These three account for about 85%-90% of the FEA pre/post software... One of the biggest issues with Linux is getting consitent OGL performance and quality. These tools heavily depend on OGL.


OpenGL performance on linux is a major agrevation. Everytime I'm doing it on linux I wish I was back on my Octane at home. And OpenGL is one of the major issues keeping me from being whole hearted about moving most of my work at home to OS X.
unixmuseum wrote:
jdboyd wrote:
I've seen other people say that as well. Yet, I have three linux machines here, one with 1 gig, and 2 with 2 gigs, and I don't recall doing anything to make them see and use the entire ram. One of the machines is using a stock RHEL 3 kernel, one is using the stock RH9 kernel (because I haven't changed it yet),

No, this is not the issue... It "sees" the memory, can't address bigger chunks...

jdboyd wrote:
Is the real issue that a single application can't use more than 800 megs? Even still, on the RHEL box I've run a program that used 900 megs.

That's more like it. Quote from the NX Nastran Installation & Operation Guide:
Quote:
Linux Memory Allocation Limit on 32-bit Platform
The standard Linux memory structure only allocates approximately 850MB of memory for an NX Nastran job. This is a limitation of the Linux operating system and not of NX Nastran. If you re running NX Nastran on a Linux operating system, and you want to access more than 1GB of physical RAM on a given machine, you must install both of the following:
    - either the kernel-bigmemory patch or the kernel-bigmemory kernel, available from: http://rpmfind.net
Together, these two patches allow your system to allocate more than 850MB of memory.


So maybe RH bought a clue and uses the bigmem patch by default then.

This whole linux thing is pretty irritating anywhich way around.

I used to love linux, but as I've gotten deaper into it over the years, my love turned rapidly to loathing.

Though it does do some very handy things, like read efs CDs and do loopback devices (OK, lots of OSs do that, except Irix), and support hardware that is otherwise Windows only. I certainly can't go do away with linux much as doing heavy work on it drives me batty.
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.
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.
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.
TeeTylerToe wrote:


Not at all new, but they are nice looking, not to mention relatively cheap.

I wish they would loosen up and either support linux or release the info needed for others to write linux support (or Irix for that matter). I'm using AJA cards instead for the linux support. These cards a good bit more expensive, but blackmagic just doesn't care about anything but the mac/windows desktop.
zolotroph wrote:
jdboyd wrote:
I wish they would loosen up and either support linux or release the info needed for others to write linux support (or Irix for that matter). I'm using AJA cards instead for the linux support. These cards a good bit more expensive, but blackmagic just doesn't care about anything but the mac/windows desktop.


Well, the total lack of professional video applications for Linux (aside from smoke/flint) might have something to do with it...


There is Shake, Houdini, Maya, RaveHD, several NuCoda products, Bones from Thomson Grass Valley, Oxtel Imagestore 300, and many others, and this is ignoring the numerous people who are doing embedded systems.

Now, AJA, DVS, and Bluefish444 all support linux, but they all cost an arm and a leg. The Aja cards are over a grand for plain SDI cards, and the DVS cards are $5k for plain SDI cards. Bluefish is somewhere in between I believe.
zolotroph wrote:
I'm guessing that compositing and 3D apps by themselves aren't nearly lucrative enough of a market for video card companies to support Linux. If popular editing apps like Avid, Vegas or even Premiere Pro (shudder) had Linux ports, the sheer numbers would make driver development much more worthwhile for the card vendors. Just a guess...


Well, there is Cinelerra (shudder).

That said, there is more than just editing software. Any company that wants to use BMD cards in an embedded system might well be buying hundreds of cards a year. I realize that this isn't considered high volume by BMD (I believe they don't consider any order less than 10k units to be high volume), but the cost to allow companies to get the specs under NDA and have a person to provide part time support can't be all that high. AJA and DVS certainly find it worthwhile. They even give OEMs and embedded systems people a discount on the products.

I bet that AJA and DVS customers would flood to BMD for new product designs based on pricing as the discount either AJA or DVS give still doesn't bring the cards down anywhere near to the cost of the BMD cards.
Stonent wrote: I guess the graphical people would use SGI at work and Mac at home, but I certainly couldn't see Unixy people using SGI at work and a Mac at home (at least in pre-osx days)


A fair number of Unixy people would have used Indys for workstations and Challenges or O2ks as compute farms.

And for some reason I've always had the idea that unixy people were more likely to like the Mac than a PC. After all, Clifford Stoll wasn't exactly a graphics guy (at the time admining BSD Unix on Vaxen), but he made mention of having a Mac at home in "The Cockoo's Egg". I've heard many other reports of unixy people buying Macs of the MacII, IIFX and SE/30 variety for speed reasons, not to mention A/UX or MachTen from Tenon Intersystems.
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.
It would be cool if people would test it on older machines, like R4.4k Solid Impacts and lower.

Wings runs acceptably on a P166 with 3D accelerator (I know I tried a Voodoo3, and a Riva TNT), so it would be really cool if it could also perform on older SGIs like Indys and/or Crimsons.
bjames wrote: Just wondering how the O2 (AV-1) video quality would compare to a Miro (Pinnacle) DC-30 board on a wintel machine, specifically image quality during capture and printing to tape. I used to use the DC-30 with Premier 5.0 and was reasonally satisfied with the performance and quality for what I was using it for. Below is a comparison of the my old wintel system and my O2 that I dont have setup yet. Can anyone provide their opinion on how the two machines may compare in performance? Just wondering if I sould look at upgrading to the digital video option.

Miro DC-30 Machine
Win NT4.0, SP2
Dual P2 350mhz
512 mb ram
single IDE hard drive UDMA-66 (6 gig)

O2 R10000 250MHZ
512mb RAM
AV Option (AV-1 analog)
18 gig 10K RPM drive
(6) SGI 4 gig external disk array - Raid 0 for video


Quality wise, I don't know that one is vastly better than the other. Unless you have a specific need for SDI, I wouldn't upgrade to the digital video option. Even then, I'd rather wait to find a Miranda VIVO.

However, I thought that R10k O2s were bad for video (some clash that was fixed in the R12ks and never a problem in the R5ks, R5.2Ks or R7ks).

Also, should you decide to actually use the O2, I would replace the external array with a single relatively new 18 or 36 gig drive in an external case. Single SCSI drives that will do 35MB/s aren't that hard to come by cheaply.
bjames wrote: Isnt that 35mb/sec burst rate? Right now I have 6 of the PG4 SGI stripped as one volumn that will do uncompressed video without dropping a frame aprox 27mb/sec sustained. Becuase I will be working with compressed video, I shouldnt need anything near that data rate. 12mb/sec sustained should be fine using 3 or 4 of the PG4 drives.


The 35mb/sec was a measured rate, not a manufactors spec for burst rate.

The only thing I have against using compressed is that you only get one video stream. I would like to be able to have multiple video streams going at once. Striping 2 of those disks (I'm sorry, I'd post the model, but it isn't convienient for me to look at the drive in question) on 2 busses is just about perfect for that.
bjames wrote: Are these 10K or 15K rpm drives? My O2 has a 18gig 10K RPM system drive. I think the PG4 drives are 7200 RPM each.


10,000 RPM. The drives are U160 drives.
GIJoe wrote: it's premiere 4.2 in crash-edition tho, running on the least supported platform. don't expect too much. a mac mini intel with one of these firewire-video converter thingies with analog i/o will probably take a day to edit and encode what your o2 will take a week for. ;)


Of course, who says you have to encode on the same machine you edit on?