The collected works of foetz - Page 36

dexter1 wrote: dissing opensource projects is not the way to increase our enjoyment and productivity on our SGI's. So let's not do that, but instead focus on what does work

that goes hand in hand. to know what works fine we need to know what sucks or vice versa :P
r-a-c.de
necron2600 wrote: with Ruby I can create webapps.. manipulate LDAP or Database servers, etc.

you can do that with php
r-a-c.de
Vladio wrote: I have the Irix 6.5 foundation set and a couple overlay to get to 6.5.29 for my Octane, is there anything more needed for the Onyx 2?

nope, just fire it up :-)
r-a-c.de
Vladio wrote: I procrastinated getting an adapter for the semi-odd video connector SGI used and that should be here tomorrow.

ah, for additional video hardware what comes with irix might indeed not be enough. it depends on what sort of video gear you have. some need specific drivers supplied by the manufacturer

Right now I'm setting it up through serial connection. Thanks again!

no prob at all and for installing it, unlike the workstations, you need to do it via serial anyway
r-a-c.de
rosehillbob wrote:
foetz wrote: no prob at all and for installing it, unlike the workstations, you need to do it via serial anyway


Actually that statement is incorrect. You can and should install OS without serial cable on a ONYX2 (assuming it has Infinite Reality card set) to get the Xserver properly setup.

well, at least for a rack onyx2 you have no other choice but serial

Vladio wrote: Got it sorted, I was clicking off on a conflict that I shouldn't have.

I got 6.5 installed with Overlay/installation disk 1 and 2

which overlays?
r-a-c.de
Vladio wrote: I have the set 6.5 base, foundation.... whatever the first iteration of 6.5 is. Mine has two disks labeled overlay/installation 1 and disk 2.

it seems your 6.5 base set has additional cds. the actual 6.5 base has nothing called "overlay". in doubt skip those.
r-a-c.de
mia wrote: Foetz, could you explain how to install and setup sshd using the packages you have provided?

which ones? the set based on openssl 1.x or the first one?

Note #1
It seems that curl (RACCURLBASE740) depends on RACSSLBASE098 but openssl_098zg.tar only registers:
RACSSLBASE198 installed OpenSSL 0.9.8zg
perhaps openssl 0.9.8zg should register RACSSLBASE098 instead of 198?
But, it works fine with openssl_098ze.tar

might be a typo

Note #2
svn (RACSVN155) requires RACICONVALL11 but libiconv installs RACICONVBASE112

yeah iconv was one of the first packages i made after 12 years or so. seems i was a bit rusty :P

Note #3
the latest sudo (1.8.14p3) compiles and run fine, but I had to replace EOVERFLOW with ERANGE.

well then do provide it :-)


i haven't forgotten about the things mentioned last time. just quite busy at this time of the year. will get to it once the dust has settled again :P
r-a-c.de
sure, in this case it's just doing it manually for the reasons mentioned before.

grab openssl_102d.tar.bz2 and openssh_71p1.tar.bz2. extract them and throw them into /usr/local. you might have to add the lib dirs to your LD_LIBRARY_PATH and of course the bin dirs to your PATH if you feel like it.
that's all, no setld stuff in this case. depending on your env vars you can have these side by side with the older ones which come as setld kits :-)
r-a-c.de
glad it worked out. that's a great box you have there, i hope you'll have tons of fun :D
r-a-c.de
well grep through your includes and check for stoi
r-a-c.de
no idea i'm afraid. i never used any kind of remote desktop on tru64
r-a-c.de
i'd guess so. just give it a try :-)
r-a-c.de
no clue. just compile it again, should go through without hassle
r-a-c.de
  • lynx_288r2.tar.bz2
  • links_212.bz2
  • rsync_311.bz2
  • emacs_223.tar.bz2

i also tried perl 5.22. it took quite a while and then there was some error. i didn't have time left to check it but tru64 does come with quite a useable perl already so it shouldn't be tragedy :P
rsync and links are just the binaries because that's all there is.
emacs 22.3 is the last version with osf support.
r-a-c.de
  • php_5530.tar.bz2
  • php_5530_apache24.tar.bz2
  • php_5530_ext.tar.bz2
  • apache_2417.tar.bz2

this is a special set for techgrrl but also for anyone else interested in using their sgi as a webserver of course.
the first php has no special sapi and can be used as fcgi with any webserver supporting it or of course for just running php scripts otherwise.
the second one contains as the name suggests the sapi for apache 2.4.x. copy the module from its dir to the other apache modules and edit the config accordingly.
the third php package contains the modules. i built php without much additional stuff to keep it flexible so in most cases you wanna grab the modules as well and use whatever you like. there's quite a bunch of them inside.
apache is, well, just the latest of the 2.4 branch. built with all modules so you can pick whatever you favor
techgrrl wrote: This is awesome, and I didn't even know there were other download directories there - is this mirrored anywhere?

as mentioned before, check the first post of this very thread :-)
just run everything behind a router/firewall and you're fine. general, golden rule; goes for all systems.
then you can surf and whatever else you wanna do with your sgis and any other specials you might have
r-a-c.de
you could also move "bool theSame=false;" out of the loops. declare in advance, only set within loops
r-a-c.de
rulp wrote: Power Animator 9 (or any Alias software)

yes, dispatcher. however alias was 95% irix except for standalone renderers for 8.5 fot nt and i don't think you wanna fiddle with aix machines from the 90s in this case

Wavefront Advanced Visualizer (or any Wavefront software)

yes, mental ray. not included

Houdini

yes, mantra. regular houdini installation is enough for the slaves

Maya 1-6

yes, dispatcher for the native renderer and mental ray if you have the extra standalone mental ray for maya

Softimage

yes, mental ray. regular softimage installation is enough for the slaves

Any other software you guys can think of?

renderman flavors. see each one for details

Furthermore, how would I do it?

that's different for each one
r-a-c.de
interesting that the changes had so much more impact on irix
r-a-c.de
if you wanna beef it up more you could replace the iostreams with c stuff and use static inline for generateRandomNumber()
r-a-c.de
the 600mhz octane beat the 2ghz power5? :shock:
r-a-c.de
"runon" is what you're looking for
r-a-c.de
so the single r14000/600 matches the power5 at 2ghz? :P
r-a-c.de
just use zsh if you like it fancy :P
r-a-c.de
a first step would be telling us which version you're using and which product exactly
r-a-c.de
yes you're right, one review was missing but it's coming right now! hold your breath ladies and gentlemen for the last one of the true 3d classics:

TDI Explore
tdi.png
tdi.png (46.47 KiB) Viewed 792 times


INTRO
founded in late 1986, the french company Thomson Digital Image (TDI) stood on its own feet after being part of Thomson-CSF for 2 years. starting as a request from the french national institute for audiovisualisation it took not even 2 years before TDI became its own master. thanks to free promotion by the french tv stations it quickly became successful enough that ibm bought 49% in 1989. that did however last for 3 years only and one year later in 1993 TDI was bought by wavefront technologies. and not so long after that they found themselves under the roof of sgi after alias|wavefront had been created.
this is also the version i'll use for the review here so although the title reads TDI Explore the following review is based on quite a late version (4.2.1) from 1995 when it had the a|w branding already.


REVIEW
like some of the other classics Explore is not one fat single program but a cooperation of several independent ones including one unique element: a menu bar!
yes that's right, starting Explore doesn't get you any gfx program at first but just a horizontal bar across the whole screen at the very top of your desktop. a launch bar you could call it with some additional features.
just like most other 3d packages Explore depends on a bunch of environment variables which must be set at first. particularly important are GRAPH and PROJ. without these pretty much nothing will work :P
GRAPH is the general root dir of the Explore project directory structure like Softimage's "databases" for example and PROJ is the name of the project that you wanna work with which is then created automatically inside the directory structure pointed to by GRAPH. so every "master" dir under GRAPH will get another subfolder named after whatever PROJ is set to. now as you can imagine that's a bit clumsy for extracting a single project for backups or other reasons but fear not, Explore comes with a bunch of scripts for exactly such purposes. the project files are script-like as well. be it the scene description data itself or info for the renderer to use in addition. these 2 are the minimum for actually getting some image out of it.
and by that we're good to go so without further ado let's head straight to the first actual program which would be:

3Design
the second most popular component of the Explore package is the modeler. quite a neat one i have to add which is also the reason why it was shipped with other a|w products, too. the usage and looks were different from what other companies had. for one because there were no menus at all. everything was done by either hotkeys or different popup menus you get by using the mouse buttons. as you'll see one the pics later like PRISMS the screen was divided into 3 viewports instead of the common 4 which is actually not such a bad idea. you can also customize the colors of pretty much everything which is then saved per project. this is neat because that way you can have different looks applied to different projects automatically.
the modeling features are quite good for the time. a proper set of spline and poly tools in addition to some general functionality. as usual for complex applications there're a few stumbling blocks for new users. one of them is that before you create anything you have to pick a reference object. in case of a new scene the only choice is the centered world object. that part becomes even more impotant when we get to the animation unit.
just like with wavefront groups play a major role. especially when it comes to assiging materials at some later point. while that might be a slowdown for the quick and dirty project it also has advantages. you can for example asssign just parts of an object to one group and the rest of the object to another or split that even more ... you get the idea. by that having multiple materials and textures for one single object is no problem at all.
late versions of 3Design could read and write 3 file types:
  • the original TDI type: face
  • the wavefront type: obj
  • and the alias type: wire

anim
you guessed it, this one is the program responsible for animation :P
but using anim is mandatory even if you don't actually animate anything. it's the program that creates the files required for the renderer. later Explore versions have ways of doing that from within 3Design as well but that's kind of messy. also important is that for loading anything it has to be in the classic TDI face format.
anim is not straight forward. you have to perform specific tasks in a specific order to get what you normally would expect which at least for me is the main reason why Explore is not my first choice for quick projects. i'm not gonna elaborate that in great detail because that's pointless unless you're an actual user. in that case however if you should have some problems in that regard feel free to pm me :-)
the animation features include not much more than the usual stuff and the program looks exactly the same as the modeler except for different menus of course. another special is that none of the viewports do provide a look through the camera. only a small window which you have to bring up explicitly does that.
once you've imported and arranged your models you hit the write function which creates the 2 mandatory files mentioned before. now you're set to move on to the next stage:

IPR
ah yeah, for maya users this one should ring a bell. indeed this is the original of what you're using in the render window. IPR means InteractivePreviewRender which is eactly what it does. Explore doesn't have shaderballs or similar material previews but does use the complete scene for that purpose. that's also the reason why you can't load IPR just from scratch but have to provide the render script you got from anim as well as a special image you have produced in advance. so when i said "move on to the next stage" at the end of the earlier paragraph that was actually wrong because the next step after you're done in anim is hitting the renderer for the first time and creating this special IPR image of your scene.
no worries there tho because that's fast and easy.
now although IPR is famous for its preview renderings these are actually just a side effect of IPR's main purpose: materials and textures. and at the time that was amazing!
IPR had fully customizable shading networks which other programs only had years later. if you didn't like the gui you could alternatively edit the rendering script manually which is relatively easy if you've seen something similar before. however like with anim usage here was not too intuitive either. again you have to follow a specific order of things to do for getting stuff done. naming was somewhat limited as well. you could only overcome some of the limits by editing the renderscript manually.
another trap is that all shadows are off by default and without knowing where to look you're not gonna stumble over that either so new users have to prepare for running against some walls at first.
one more obstacle are the lights. their normal range that's shown in IPR by default has pretty much no effect. the mean thing now is that you might not notice that at first because by default ambience is at 100% :P so turn that off and crank up the light seriously by entering the values by hand.
as a last special i should mention the somewhat hidden menu that controls what you usually consider the renderer settings. pushing the right button or just hitting F11 brings it up and there you can activate the so far missing shdows and a bunch of other quite handy stuff. with a little tweaking you can even set it so that you can render a shadow pass for example.
once you know the tricks it's quite nice tho and leads us right to the next and final stage:

render
yup that's right, it's just called render but it's good and fast. it takes quite some options so unless you're feeling brave start it via gui and set whatever you like. as you can see on the screen shot there's quite a bunch of them and they're good. yeah i keep saying "good" in regards to the renderer and that for good reason (pun intended). assuming you handled IPR right it just looks good no matter what you set. well of course i do assume you have rendered stuff before so with a little common sense you should get really nice results and that fast. considering the speed the results are even great.
produced images are saved in the native .tdi format which can be viewed and converted by some of the included tools that also have a button on the main menu bar.


MISC
a few more words about the menu bar and its usage.
the easiest way is just hitting one of the buttons but that won't work initially. instead you have to set some options first which is done by clicking the black square in the lower right corner of each button. once set you can hit the button directly next time unless you wanna change the options again.
some buttons do nothing but just contain a submenu with even more buttons. these are the ones with the arrow icon instead of the square. they're mostly used for management tasks or the image view program which is simply called "display".
or imgcvt which is quite a versatile converter. here's a copy of the original help message:

Code: Select all

FORMATS
The following image formats are supported:

image formats                      extensions           modes

Abekas NTSC or PAL                    yuv                rw
Alias                                 als                rw
Explore                               tdi                rw
GIF                                   gif                r
JPEG JFIF                             jpg jpeg           rw
Kodak Cineon                          cin                rw
LucasFilm                             lff                rw
Pixibox PXB                           pxb                rw
PNG                                   png                rw
PPM raw/ascii                         ppm                rw
Prisms                                pri                rw
Quantel                               qtl                rw
SGI                                   rgb sgi bw icon    rw
Softimage                             pic                rw
Targa RGB/BW                          tga                rw
TIFF 6.0                              tif tiff           rw
Vista                                 vst                rw
Wavefront RLA                         rla                rw



PERSONAL
yes, Explore might have some quirks but also some great ideas that most other programs only had years later if at all. the renderer is very good and fast and the menu-less and right click based workflow is very effective especially when combined with hotkeys.
it's not a program where you feel in charge after 15 minutes but once you do you have some powerful tools at your fingertips.
for this review i used Explore 4.2.1 running on IRIX 5.3 on an indigo2.
i've never seen older versions from when it still was TDI so if you should have it please do share some pics and info if you can.


speaking of pics, here they come :D
r-a-c.de
escimo wrote: @rem Which file do you mean exactly on this site? :roll:

if you can't find it you're not supposed to have it :P
SiliconClassics wrote: Well done Foetz, thanks! Did it come with any sample scenes?

hmm good question :P
it comes with a nice shader collection tho. i usually don't install samples but i could check the cd ...
r-a-c.de
don't go, most other forums only have ten-year-olds :P
r-a-c.de
BLAiSE wrote: I think lot of "old" software are capable to do serious work.
...
The system and the software was almost flawless so I can't imagine at the time, what will be the next step, because with Toonz you were capable to do everything what was needed for traditional animation work. The software had all the features what we needed, it was well written optimized code, the workflow was fast and efficient on those 200-300MHz computers.
So they fucked up the whole thing, just as the XSI. (Although this was an independent coder division in Italy). Toonz 5.0 was a totally new ware with pure Windows only codebase, new user interface and full Flash support. It was slow (even with 1000 MHz processors), buggy, it had lost a lot of features (they added them one-by-one, slowly in the following ten years). This was my first encounter with the new era: the 21th century software development.

this is a great summary of what unfortunately happened way too often and still does happen.

the primary problem is that the companies need to continue selling stuff so when something has reached a state where it's just good as it is they can't just stop but have to find other ways of getting the bucks. often the next steps in such cases don't change things to the better.
also to blame however at least to some extend are the users. most people want something new regularly for no actual reason and the software companies fuel that of course by telling everyone that only the latest is the greatest and if you don't have that you suck :P
many times i've seen how people react if a certain program or hardware has reached its eol. some even panic and immediately start to frantically search for an alternative. if asked whether there's an actual need for an upgrade or whether there's something wrong with the current version they hold on for a second, start smiling and admit that actually there's no need right now :lol:
r-a-c.de
this is a tricky one and i can relate to everything that has been said so far.

of course the main purpose of this forum are tech matters but why do we have an "everything else" section then at all?
also, i think it's safe to say that the niveau of the members and posts here is well above average so it might be particular intersting to read what these people have to say about non-tech matters ... for as long as it's in a civilized way of course :P

as dexter1 said already there's no staff section available so discussing general guidelines regarding what's okay and what's not turns out to be rather tricky as well as talking about something with more than one other mod. for that reason most calls are made by whoever is on the task first.
so if anyone should think a certain action was not fair please do feel free to say so. this is a great place with tons of unique information and people and it's up to all members no matter which rank to keep it that way :-)
r-a-c.de
SiliconClassics wrote: Yes, please :) It would be great to see some screenshots and renders of sample scenes.

the problem there is that most of the programs from that time had rather humble demos/tutorials included. it's not good marketing if the user has to wait for 3h when pushing the button of a demo and considering that the Explore version i have still supported the r3000 ... you get the idea.
in other words most demos don't show what the program can actually do and not to forget the different expectations 20 years ago regarding what was considered "good"; things like bad textures and ample use of ambient lighting as you know so the only reliable way of checking what a software can actually do is putting together a demo scene on your own.
r-a-c.de
ha, thanks for the feedback. glad it works fine for you :-)
r-a-c.de
i hope he'll reconsider. even if you don't share his opinion his posts are just a great read over and over again :D
r-a-c.de
icebalm wrote: My only question is how steadfast is the community about using the MIPSPro compilers? My understanding is that with gcc 4.7.1 the MIPS code generation is pretty tight?

in some cases gcc is the only choice but in any other case, as on pretty much any proprietary system, the native compilers are best. gcc did improve to some extend over the years but recent work on firefox3 as well as a couple of tests i ran a few months ago showed that gcc significantly lacks in multiple ways.
nevertheless nekoware contributions of any kind are welcome of course as long as they're reasonable. for example new does not automatically mean better so updates should be actually justified and not just for the heck of having the latest.
as mentioned by dexter1 already and many others in the past we have the general convention that gcc builds should have "gcc" somewhere in their name.

other than that, fire away and thanks for any submissions in advance :D
great, much thanks for the guide :D
r-a-c.de
dreadbit wrote: he said that it traps in fontconfig and I should temporary get rid of the OpenCSW version of it

temporarily remove the opencsw stuff from your env vars and run it again. if that should work you could create a very simple wrapper script for starting it up
r-a-c.de
ledzep wrote: I just want an option for my Linux set-up, either a hodge-podge of Motif/CDE/KVWM/whatever or Maxx working. I like KDE but it's not the same. It's not the same. I want that old-school Magic Fucking Desktop. Fully-functioning or just the visuals, but something!

I tried going the BSD Unix route and trying to force-feed PC-BSD to my version of Grub (from Ubuntu 12.04) but got nowhere. I would have accepted Motif/CDE in that scheme. But I guess I just have an old version of Grub that hates ZFS. I will try again with Ubuntu 16.04 when it's available, maybe then BSD Unix will be in Grub's sight.

how about solaris10? original cde, zfs, grub and real unix with a serious compiler. doesn't get any better on x86
r-a-c.de
this is probably trivial but for some reason i just can't see the right way. i tried a couple of ways but no luck :P

i want to make a gimp plugin that can read (writing would be the next stage) wavefront images. rla and rlb which are almost the same. of course i had a closer look at the other gimp plugins for file formats but different formats are, well, different so i didn't see enough similarities to apply it to this case.
i have a sample here from wavefront (full demo attached):

Code: Select all

for (scan = rlb_head.window.bottom; scan <= rlb_head.window.top; scan++) {
/* check for black regions outside active window */
if ((scan < rlb_head.active_window.bottom) || (scan > rlb_head.active_window.top)) {

/* write out a blank scanline */
fwrite(blank, 4, width, out);
} else {
/* seek to file location */
if (fseek(fp, (long) offset[scan - bottom], 0)) {
printf("rlb file incomplete!\n");
exit(-7);
}
/* read red scanline */
fread(&len, sizeof(short), 1, fp);
fread(buf, sizeof(U_CHAR), (int) len, fp);
decode(buf, red, (int) len);

/* read green scanline */
fread(&len, sizeof(short), 1, fp);
fread(buf, sizeof(U_CHAR), (int) len, fp);
decode(buf, green, (int) len);

/* read blue scanline */
fread(&len, sizeof(short), 1, fp);
fread(buf, sizeof(U_CHAR), (int) len, fp);
decode(buf, blue, (int) len);

/* read matte scanline */
fread(&len, sizeof(short), 1, fp);
fread(buf, sizeof(U_CHAR), (int) len, fp);
decode(buf, matte, (int) len);

/* write out RGBM for each pixel */
for (x = rlb_head.window.left; x <= rlb_head.window.right; x++) {

if ((x < rlb_head.active_window.left) || (x > rlb_head.active_window.right)) {
fwrite(blank, 4, 1, out);
} else {
fwrite(&red[x - left], 1, 1, out);
fwrite(&green[x - left], 1, 1, out);
fwrite(&blue[x - left], 1, 1, out);
fwrite(&matte[x - left], 1, 1, out);
}
}
}
}

all fine and cozy. i do of course not want to write to a dump file but hand it over to gimp. the gimp stuff is as follows:

Code: Select all

image_ID = gimp_image_new(width, height, imgtype);
gimp_image_set_filename(image_ID, filename);
layer_ID = gimp_layer_new(image_ID, _("Background"), width, height, gdtype, 100, GIMP_NORMAL_MODE);
gimp_image_add_layer(image_ID, layer_ID, 0);
drawable = gimp_drawable_get(layer_ID);
gimp_pixel_rgn_init(&pixel_rgn, drawable, 0, 0, drawable->width, drawable->height, TRUE, FALSE);
tile_height = gimp_tile_height();

...

gimp_pixel_rgn_set_rect(&pixel_rgn, data, 0, 0, width, height);

the important part here is the last one which actually puts the data into gimp. data is guchar i.e. glib's unsigned char. as a pointer.

the thing that made me struggle now is to change the fwrites into something else that i can use for writing to some dummy variable i allocated in advance or whatever else does the job.
also i wanna emphasize that this is not a commercial project in any way. in fact i'd like to share the finished product here in case i get it done somehow :P

any ideas or help in whichever way would be welcome :-)
r-a-c.de