SGI: Computer Graphics

The True Future Of Blender On IRIX, By Ton Roosendaal - Page 2

I have to jum in this discussion...

blender on IRIX interests me quite a bit, because it is a nice piece of software, because it is small and light etc etc... (also essentially the only decent 3D package you get for irix, mac, linux and windows...)

right now I am overly busy, but some months ago I tried to get involved in the irix effort. I got the nice help from guys as Hos and other chaps from the blendercoder channel, including ton himself (to be honest, ton makes always correct statements, often says true things but is rarely of real help...).

I found it very difficult to compile blender on IRIX, compared to other platforms. The configure system came in but worked badly. I think it is out again. THe whole thing is full of small things to check for if you system is not "standard". The effect that I tried to build on three or four computers with gcc 2.95, gcc3 and mipspro and rarely succeeded. I remember I got it really building only on one I think.
It is a problem with the pre-built libraries for example...

I needed this because that crappy ghost thing is full of big and small bugs on X11. Yes, the bugs affects linux and irix and solaris, but often you don't notice that on all platforms. THe problem is, there are few/no skilled developers for X11.
Specifically there is abug that causes an incredible CPU usage on IRIX with mouse position tracking, you can notice that very well on older, express based boxes. I notice it little on a 5K indy and not at all on an octane, but my indigo2 RK4 with XZ... I cn get the CPU to 100% by just moving the mouse! A pity, because even that old machine is actually better to model than my iBook (and belnder on my centrino with radeon just plainly sucks).

Thus SGIs, even if really old, are still quite nice to model in wireframe. For rendering you might move the scene elsewhere.

thus I wasn't really able to help out in blender, I was able to build and check proposed patches... but little more, I have no X11 and OpenGL coding experience. I remain open to support everyone in an unofficial way though. Currently I am not able to get official due to time constraints, not only knowledge constraints.

Then there are many small details that make blender slow on older machines or even buggy to use due to openGL differences. THings which are often even useless (I think about those stupid new menus). And generaly the new ui is "heavier". I miss some things of the old gui. I'd like a cross-breed of them.

another thing that I'd like a lot is blender classic: IRIS GL is much much faster than OpenGL on the same hardware that supports it. There is a blender version that has both binaries and runs also on irix 6.5. I tried it on my indy and my indigo2 and was impressed. Really.

getting glut to work on IrisGL? A Dream.

skywriter has that blender classic project. Imagine blender working on your 4D series, indigo1 or Crimson? wouldn't that rock?
running blender on a skywriter?

skywriter is a very nice chap, but in 2 years I was never able to do anything with him. He has a chronical lack of time and old blender sources are a bit out of order. ANyway I still hoep that we can get together and spur interest in other peoples.

if possible, both paths could be walked: keep new blenders on irix as long as possible (as long as opengl 1.1 can be used or 1.2...) and our own blender fork, starting from an old version and then maybe updating it here and there with interesting new stuff (raytracer, some new UI things, subdiv. surfaces.... and other cool things that got in in blender 2.x) and leaving out useless stuff.

have fun and feel free to contact me for any development help. But don't ask too much :)
I've also been trying to build blender with gcc. I've got both 2.37a and the current CVS to build with a bit of mucking about but they both core in the STL before blender even gets started. I gave up. I don't have the real compiler.
FYI I think it's impossible to build Blender with gcc. The problem is that it needs to link in the GLU library, which brings the SGI C++ library libC with it, which conflicts horribly with gcc's own C++ library, libstdc++. Someone else had similar problems with other things, and as far as I know there's no solution - you can't compile C++ programs that use GLU with gcc on Irix. If anyone knows otherwise, pipe up!
gandalf wrote: getting glut to work on IrisGL? A Dream.

One of the key differences between IrisGL and OpenGL was that OpenGL was platform independant and thus didn't contain the support for window management and fonts that was in the original GL. GLUT was an attempt to recreate (some of?) the missing functionality using X11 and OpenGL. So, it should be possible to create a GLUT over GL; in fact it should not be more than some kind of a wrapper. Then again, it's been awhile that I did serious work with IrisGL.

gandalf wrote: skywriter has that blender classic project. Imagine blender working on your 4D series, indigo1 or Crimson? wouldn't that rock?
running blender on a skywriter?

Stop teasing me 8)

lewis wrote: FYI I think it's impossible to build Blender with gcc. The problem is that it needs to link in the GLU library, which brings the SGI C++ library libC with it, which conflicts horribly with gcc's own C++ library, libstdc++. Someone else had similar problems with other things, and as far as I know there's no solution - you can't compile C++ programs that use GLU with gcc on Irix. If anyone knows otherwise, pipe up!

What about compiling your own from source, with GCC. Make it a static library and you don't have a clash with what's on IRIX already.
To accentuate the special identity of the IRIS 4D/70, Silicon Graphics' designers selected a new color palette. The machine's coating blends dark grey, raspberry and beige colors into a pleasing harmony. ( IRIS 4D/70 Superworkstation Technical Report )
Your own GLU? That would be quite a task, I think... I wonder how the Mesa one compares...
lewis wrote: FYI I think it's impossible to build Blender with gcc. The problem is that it needs to link in the GLU library, which brings the SGI C++ library libC with it, which conflicts horribly with gcc's own C++ library, libstdc++. Someone else had similar problems with other things, and as far as I know there's no solution - you can't compile C++ programs that use GLU with gcc on Irix. If anyone knows otherwise, pipe up!


i don't know about the last sources. but up until i quit on it, it was compiling on a pure gcc machine, then something broke.... i forgot what, but i thought it was something with either the build system (blah, had to hack some ugly stuff) or STL crap.
jan-jaap wrote:
gandalf wrote: skywriter has that blender classic project. Imagine blender working on your 4D series, indigo1 or Crimson? wouldn't that rock?
running blender on a skywriter?

Stop teasing me 8)



well the 1.8 version and build system (if you figure it out, and it's not too hard too) do work on those old machines. the point of the classic project was to bring the non-c++ blender core back to 1.8, before all the swizzle-glop-gnu-junior-code(tm) was added. but *bing* cronic lack of time. even worse now.
Okely dokely, I've managed to compile the latest CVS with gcc. I had to build libGLU from the OpenGL sample implementation source, which was an adventure in itself, but that removed the dependancy on Irix's C++ libraries and all was well.

Comparing 2.37a built with MIPSPro to my own gcc build, my build is about 20% slower doing the crude draw benchmark. The latest version is about 10% faster, though.

I'll try and package it up, or maybe wait for the 2.4 final, if anyone else even cares :)
lewis wrote: I'll try and package it up, or maybe wait for the 2.4 final, if anyone else even cares :)


Of course cares!; Those are really cool news!
I'll give it a try as soon you have it posted.
Cheers! ;)
lewis wrote: I'll try and package it up, or maybe wait for the 2.4 final, if anyone else even cares :)


so, 2.4-pre still compiles with MIPSPro? that would be nice place to fork, before the opengl 1.1+'s inch their way in.

edit: since it really is a pain in the ass to setup a compilation without an external libs CVS site to download them (python lib, jpeg lib, zlib, etc...) from. there are way too many external GNU-ish crutches to make this easy to compile by itself.
lewis wrote: Cool... would be good to know if your build has the International Fonts working, mine with gcc does not - they don't render at all. I presume this is because something in FTGL is broken. Fixed my particle issue, it was an alignment thing which shouldn't be a problem with MIPSPro, but Hos has committed the fix anyway.

Wanna compare some benchmark type-things when you've got a build?

BTW I wouldn't try gmake -j parallel building, it tends to not work for some reason.


...mmmhhh ...The build was finished about two hours ago, bombing out with:

Code: Select all

17:34:23 (sgifd) IN: "cpp" root@IRIS
gmake[1]: *** No hay ninguna regla para construir el objetivo `/usr/nekoware/lib32/libfreetype.a', necesario para `/WareRoot/bf-blender/blender/obj/irix-6.5-mips/bin/blender'.  Alto.
gmake: *** [all] Error 1
gmake: Leaving directory `/WareRoot/bf-blender/blender'


Which aproximated translation is:

Code: Select all

17:34:23 (sgifd) IN: "cpp" root@IRIS
gmake[1]: *** There is none rule to build the object `/usr/nekoware/lib32/libfreetype.a', needed for `/WareRoot/bf-blender/blender/obj/irix-6.5-mips/bin/blender'.  Stop.
gmake: *** [all] Error 1
gmake: Leaving directory `/WareRoot/bf-blender/blender'


I was working in another task, no time to check it until now... By now I've only discovered that seems I'll need to set my -LANG to:

Code: Select all

-LANG:libc_in_namespace_std=on


But no clues by now about the libfreetype error of above... what do you think?
GeneratriX wrote:

Code: Select all

17:34:23 (sgifd) IN: "cpp" root@IRIS
gmake[1]: *** There is none rule to build the object `/usr/nekoware/lib32/libfreetype.a', needed for `/WareRoot/bf-blender/blender/obj/irix-6.5-mips/bin/blender'.  Stop.
gmake: *** [all] Error 1
gmake: Leaving directory `/WareRoot/bf-blender/blender'



Well, at first glance the path is wrong, since libfreetype.a lives at: '/usr/nekoware/lib' (and not '/usr/nekoware/lib32')... now I only have to find where it is erroneously called.
I've fixed the path issues, now I only need to fix the 'MIPS4' thingy, since Nekoware is MIPS4, and by default Blender is arranged for MIPS3...
GeneratriX wrote: I've fixed the path issues, now I only need to fix the 'MIPS4' thingy, since Nekoware is MIPS4, and by default Blender is arranged for MIPS3...


Yep - I was thinking about compiling Blender myself this weekend with static MIPS3 libraries. I've done it before in the past, I just don't have a lot of spare time right now.
Twitter: @neko_no_ko
IRIX Release 4.0.5 IP12 Version 06151813 System V
Copyright 1987-1992 Silicon Graphics, Inc.
All Rights Reserved.
nekonoko wrote:
GeneratriX wrote: I've fixed the path issues, now I only need to fix the 'MIPS4' thingy, since Nekoware is MIPS4, and by default Blender is arranged for MIPS3...


Yep - I was thinking about compiling Blender myself this weekend with static MIPS3 libraries. I've done it before in the past, I just don't have a lot of spare time right now.


Hi Neko ;)
...Well, I'm pretty much in the same conditions, actually I only can work on this as a background work, while I'm sourcecoding my apps or replying mails... and then I'm doing the needed changes to the build once it bombs with some error... :P
But I think I'll be pretty much stuck for a while with this one, since I can see that it will take some more time to have a Nekoware/MIPS4 version working... and I'm actually a little bit delayed on my job.
If I have the time, I'll take a look later to see what is needed to achieve a MIPS4 build.
Cheers! ;)

P.S.: If anyone wants to give it a try with a similiar setup, the right steps actually are:

1) Add the environment variables (CShell):

Code: Select all

setenv NANBLENDERHOME /Your_Own_Path/bf-blender
setenv MAKEFLAGS "-w -I$NANBLENDERHOME/source"


2) Fix the paths on 'source/nan_definitions.mk' as follows:

Code: Select all

export NAN_ZLIB ?= /usr/nekoware


Code: Select all

export NAN_FREETYPE ?= /usr/nekoware
export NAN_GETTEXT ?= /usr/nekoware


3) Fix the paths on 'source/Makefile' as follows:

Code: Select all

COMLIB += $(NAN_FREETYPE)/lib/libfreetype.a


Code: Select all

COMLIB += $(NAN_FREETYPE)/lib/libfreetype.a
COMLIB += $(NAN_FREETYPE)/lib/libintl.a


4) Run:

Code: Select all

gmake


...But of course, previous to the 'gmake' we need to resolve the conflict between MIPS3/MIPS4 libraries to build a MIPS4 binary.
Incidentally you only need to set those two environment variables if you want to be able to run gmake lower down the source tree - if you're building just by running gmake in the root of the tree they're not nessecary.

Gonna try a MIPS4 build now before I break out ogldebug and go after FTGL. International fonts seem to be broken in the last official build so maybe it's something on my system...
lewis wrote: Incidentally you only need to set those two environment variables if you want to be able to run gmake lower down the source tree - if you're building just by running gmake in the root of the tree they're not nessecary.

Gonna try a MIPS4 build now before I break out ogldebug and go after FTGL. International fonts seem to be broken in the last official build so maybe it's something on my system...


Do you think to take the road to use MIPS3 versions of zlib, freetype, and gettext, compile Blender as a MIPS4 static?
If you do so, let me know how goes all, and the files you have "touched" to have it working. I found the build structure of Blender a little bit difficult to understand by now, since it seems to lack the presence of a centralized way to do changes... ditto: no .configure script for the older NaN Makefile, and a pretty complex three...

But I'll be happy to give it another spin anyway... ;)
nice that you guys got something to work already... I had always problems with true type fonts, even in official builds: they showed up, but beveling caused artifacts. This also on a sparc with a mesa-based and gcc build.

I personally would prefer a generic 6.5.x build and mips3/mips4. I would hate not to be able to run it on my indigo2 :) and in some future, on my indigo1! but of course intermediate steps can be taken. I think that the official BF version which just run without having to depend on nekoware or freeware was the best thing.
gandalf wrote: nice that you guys got something to work already... I had always problems with true type fonts, even in official builds: they showed up, but beveling caused artifacts. This also on a sparc with a mesa-based and gcc build.

I personally would prefer a generic 6.5.x build and mips3/mips4. I would hate not to be able to run it on my indigo2 :) and in some future, on my indigo1! but of course intermediate steps can be taken. I think that the official BF version which just run without having to depend on nekoware or freeware was the best thing.


Hey Gandalf ;)

...relative to my spins with Blender, I'm only lurking on it for a while, to see if I can understand better the build process on it, and maybe learn also a couple lessons from an app with years of development behind.

But I think I'll not be able to produce even a remotely standard build, since my development environment differs quite much from either the standardized in use for Nekoware, or the used on latest Blender's releases for IRIX. Anyway, I enjoy this task on my spare time; and if works fine I'll release a tardist later as an alternative option for those desiring to test it.

As Lewis says, could be really interesting to compare different builds to see which combination/environment works better on different IRIX platforms. But today I was working all the day with my office job without chance to continue my build...
I can't agree on that with you!

Sadly, he's right. A good AMD system running XP64 can now pull this off:

Image