I second ErV's choice. I have and use most of your requirements running (for different things anyway) and also I recommend Slackware. Despite that I simply like it, it has always been very stable and very friendly in terms of doing not-so-usual Linux stuff. I have more or less everything installed somehow concerning "Linux and graphic's and GUI (which includes OpenGL nowadays..)" and it all works fine - even heavily patched stuff or rigorously updated bleeding edge libs are all playing nicely together.

To add to ErV's choice some points more:

* Slackware does not protect you from anything. It's only made "secure" in that sense that Slackware removes and patches real security issues. If you like to optimize your system to death, you may do so.

* Slackware is tough love, not cute cuddling. A Slackware package comes as it would come out of self compiled source more or less - no package maintainer trying to do his own style on whatever. So, standard documentation or manpages or extensive Howtos and similar docs _still_ apply. In Slackware terms it's called "non-intrusive" - everything is left for the bare minimum required for a smooth running system. This really means a roof over your head and solid stone walls and a nice wooden floor, running water and a toilet but NO furniture included and you have to hang the lamps yourself.

* It requires not tweaking in the strictest sense, but it requires actually touching sources sometimes - but as ErV said - it's really just usally configure, make, make the package - I actually do a make install usally and it still works all fine.

If you still want packages: There're several sites out there supporting Slackware packages, but it's not as well equipped as a Debian repository, so sometimes things are missing and you'll have to add stuff by yourself.

I run Slackware with Nvidia binary drivers and experimental nouveau drivers and play with the X-nv driver, I have added several font patches to Xft, freetype and Cairo, I use the most recent Cairo/Gtk family, have every existing compositing manager and transparency supporting GUI thingie installed and (as far as possible) in use and an up and running Firefox from CVS with theora/ogg-in-SVG-elements support. (Sweet stuff, btw. )

So, I'm doing something totally different with underlying Open GL and Nvidia drivers and still recommend Slackware from a different graphic's related point of use.

And _all_ distributions depend on Nvidia's drivers - but there may be some day where some distributor makes a deal for some closed source additional supporting stuff with Nvidia and that would be the point where you usally lose as a Slackware user.

I wrote another long answer that explained clients and servers and everything else - clearer than anyone has ever explained them before, if I remember correctly - but lost it when the forum software screwed up. Or maybe it was my stupid IE browser? Which raises the embarrasing question, "why am I on my windoze machine now, anyway? Moron me.

The short answer is (cuz I'm too lazy to repeat it again), my server is an EXE - though it could be a DLL, and it doesn't matter cuz your code would not connect directly to it anyway (unless you had the source and wanted to do it that way). But you wouldn't want to do it that way, cuz it would be slower now - in the era of quad-core and beyond. But it supports passing the messages from a process running on the same computer through shared memory - which is more efficient then runing in the same process (due to multicore), and lacks 99.999% of the potential causes of bugs.

The reason for another API is not to replace or redo OpenGL. Fact is, OpenGL is nothing more than the functions my code needs to call to drive the nvidia or ATI video graphics hardware at full speed. That may seem like a strange way to think about OpenGL, but that IS the way I think about it - becaue it is TRUE. That is the one and only way nvidia gives me to interface to their hardware - period (on linux or on multiple platforms).

No, the reason for another API (in the form of a "server" in this case), is to provide another whole (higher) level interface. So you can create a physical object by telling the server the create, assemble, modify, manipulate a bunch of geometric components (cylinders, cones, disks, spheres, and about 20 others). This all needs to be done by hand at very low, basic level in OpenGL. The 3D server lets programmers and programs think and operate at a much "higher" level and let the details be handled by the server. Why write your own "collision detection" when the server will do it for you (and even bounce things off of each other correctly if you supply mass, density, elasticity, and other properties to the objects you create. Get the idea? Or did that just cause yet-another reset?

Thanks Su-Shee for all the good observations. It certainly appears that Slackware should be the next road I take - if my current attempt to get the latest version eclipse IDE and CDT to install, run, and successfully compile and execute my 3D engine code (that was running on fedora8 + older-eclipse many months ago).

I just managed to get both 32-bit and 64-bit ubuntu 8.04.1 DVDs to install on two separate hard drives, and they upgraded themselves just fine (which fedora9 did not). Now I need to see whether eclipse installs and runs too --- and then AARG it is time for me to try to remember how to configure and operate eclipse well enough to run my code --- gulp.

If anything goes wrong, it will probably be time to catch the slackware bus, train, automobile, plane - or rocket? Seems like no other distribution has any [graphical] advocates!

Oh, and I forgot to answer one question from resetreset. I have no resistance at all to providing my 3D simulation/graphics/game engine to Linux developers, so they can develop end user applications easier. I need the engine to build several of my own projects/applications upon, and I am happy if others can benefit too.

I'm not sure whether you were suggesting others might want to help me enhance it or not. The basics already work, though I still have a 5 page list of features and improvements I want to add, not even counting support for various kinds of physics that I need (some of which I have written before, so it won't be so difficult to do). But my answer would be "sure, I'm open to that". However, I am not much of a "people organizer", and my few previous [?lame?] attempts did not pan out. Why? Well, let's just say I am not allergic to work - lots and lots and lots of work. Or to put it another way, like others I enjoy the dream/design/envision part, but I am also willing to spend obscene quantities of time and effort to implement - cuz "I want it real". For me, dreams and pretent are not enough. In the end, this project is just one element of a large, many element project that really needs to get done. Because it will "change everything" (that can be changed) once it is finished. Though as I mentioned before, this is a "redo" - the proof of principle works, but is orders of magnitude too slow. But the new architecture should improve the speed and efficient enough to make it practical.

Thanks for your enthusiasm.

PS: I am always too busy to see what other developers/groups are doing. You might find others are doing (or have already done) what you seek.

PS: If I ever need a fun 15 minute break, maybe I'll try to regenerate that description of what a "server" architecture is (from my point of view). Fact is, the server architecture is what many developers are endlessly "looking for" to solve their complexity problems (and other problems too). But server architecture gets no press, perhaps because it is so damn successful and pervasive already that people just take it for granted and never even consider whether they should design their own applications that way. And in the world of ever-increasing growth of networs/networking and multi-core processing, server just looks and gets better and better every day. Do you know (for example) that XWindows is a server? That virtually all web-pages and website data is provided by servers? Sometimes people think servers are inherently "slow", because they *conventionally* communicate over network connections (which were 1Mbps, then 10Mbps, then 100Mbps, then 1000Mbps (gigabit ethernet)). But they forget the Linux provides mechanisms to keep that architecture, but communicate at unlimited speeds when communication is within the same computer/CPU (on multiple-core CPUs). This makes the extreme architecture benefits of "client-server" architecture available to just about every kind of application. But people are mislead away to messy alternatives that do not interoperate in every combination (of OS/CPU/language/etc) like "client-server" can. A true client-server system *never* ever cares (or necessarily even knows) what OS/CPU/language is on the other end of its communications. The powers-that-be in the computing world don't like that, of course. Of course, most advocates of Linux love this. More later if and when I get the time.

ErV, you used a SPECTRUM?!!! I come from there too! Where are you, geographically?

Yeah, I also tried to form a team once, around the work I already have. But it was amazing difficult to find anyone who wants to actually work rather than "dream" or just "join something" (and hope they end up sharing the glory that others make happen). Sometimes I wonder what "clicked" in the few collaborations that seem to have worked. It could be simply "luck" - random chance that you get more than 1 serious, talented, productive person aboard (and no trouble-makers). Or it could be that only projects that are ~ essentially done ~ attract people, perhaps because they feel like they immediately get credit for all the work that one guy or gal did already. Not sure, but I have learned to never, ever depend on anything from a "group", because that just makes your own success and happiness dependent upon things beyond your control (and very, very risky).

Interesting to hear that you've written exporters. Any importers (or is the importer considered part of the "exporter")? I have not written any for my engine, and I very much do not look forward to writing one. I considered a binary 3DS importer, but that gets into reverse engineering, which is too open-ended in size/scope/trouble to make me happy. I bought a collada book and though it incorporates many modern buzz-concepts, which I dislike, it seems like the best overall possibility.

However, in my engine, I favor a "procedural generated" approach - starting with geometric primitives and objects first, but with textures, sounds, other-aspects in my mind for later on.

I must admit, to be fair, that I have certain personal weaknesses that make me non-optimal for grubbing through "other-peoples-projects" and extending them. And as a result, my inclinations do not lean in that direction.

BTW, I have most certainly NOT spent a majority of my life working on graphics projects! So its probably more like we're neck and neck, not me way out ahead like you imagine! :-)

Russia. I guess that's why I had one. I've got used spectrum (soviet clone, technically completely identical to original, but built with russian chips) + bunch of cassetes in the second half of 90s (don't remember when exactly, was long ago, I was a kid), when it's era was (probably) already over in the rest of the world, and normal PCs could be encountered more often. Before spectrum there was a programmable calculator, btw.

No, I've never written plugin that could read foreign 3D format into 3dsmax/maya/whatever. Just didn't need it (though I could). I did wrote some 3ds and *.x parsers for my programs, but that's all.

Hmm. 3ds file format binary chunks are (relatively) well-documented online (somewhere), but the problem is that it doesn't have skinned meshes support, doesn't store tangents, normals, etc. That's if you are talking about reading 3ds into your program.

Say, does collada supports tangents, skinned meshes, animation and materials with normal-maps? I've been thinking about using some wide-spread 3d format, but, unfortunately, many of them (3ds, dxf, etc.) doesn't support skinning, which is why many games use their own formats for storing 3d characters (the only somewhat widespread format that does support skinned meshes is *.x, but there is no API for reading it on Linux, and format is a bit awkward, though it supports compression, templates, etc. Another problem is that there are too many writers/viewers for *.x format and many of then don't support skinning correctly, or don't support binary/compressed files). And I've already written too many exporters (something around 3..5 for 3ds max, 1 for maya, and there's half-finished one for blender), so I don't really want to write another one.

I found a couple descriptions of the 3DS format on the internet, but they were invariably based upon very old versions of 3DS. So I was always very afraid that I'd find all the cool 3D objects I tried to import would blow up the importer because they were saved with a later version of the software. And it seems like nobody who reverse-engineered a newer version has documented it openly to benefit everyone else.

I do believe collada supports just about every one of the features you mention, though unfortunately I don't have my book here where I am writing this email. If you want me to check more thoroughly when I get my hands on the book, I will do so. It is funny, though. From some things I read, collada seems to be taking over the universe. Yet other places (like the gamedev forums, which are pretty good) I barely hear a peep about collada. On the potentially positive side, it does seem like collada is being accepted mostly by the "serious" crowd - companies that depend on cranking out real work (3D objects, games, serious apps that need 3D, etc). So the mixed bag of impressions I have about collada lean more to the positive so far.

I would very much like to be able to import a bunch of great looking objects, since my engine already works well enough to be able to do some seriously impressive and fun demos and real work with --- except I lack objects. And I am totally NOT an artist - 2D, 3D or otherwise. So unless I get importer abilities, I will need to finish more of the procedural object/texture generating portions of the engine, then write code to crank out a bunch of procedurally generated content. The fact is, NOT having import capabilities (for now) might be good - because it assures I don't get lazy and adopt what I consider the "bad old ways" and let the "new/better ways" slip until later. Still, in the end, I definitely want to import 3D objects created with 3D content generating tools. Of course my engine does have the ability to save and load the objects it generated procedurally, but that doesn't get me anything I don't already have (in a manner of speaking).

By the way, what is an "exporter" for 3Dsmax? Something that takes objects created with 3Dsmax and saves them in some format you invented yourself? Or ??? Because that almost constitutes writing an importer, for practical purposes! Why? Well, if you load a 3DS object into 3DSmax, and then you export it in the native format of my engine (for example), the practical result is virtually the same as having written a 3DS importer for my engine. Right? I mean, in the end both approaches let my engine display objects currently saved in 3DS format.

Haven't heard about "new" 3ds format. It's an old dated file format that's not being used for serious modeling, and probably isn't changed any way (doesn't even store normals for object, only smoothing groups). Last time I needed to parse 3ds to extract object position there wasn't any serious differences with documentation, only 1..2 unusual chunk types, that's all. The only benefit of 3ds is that format is well-known.

However if by "new 3ds" you mean that you want to load *.max files into your engine, then it's not going to happen, since obejcts are stored in format completely unsuitable for 3d games, it is possible to parse this, but it won't be effective. For other well-known formats see *.obj, *.lwo, *.mdl, *.md2 (quake characters), etc. There should be a bunch of "x3d" plugins on the web somewhere which allowed to load most of known 3d formats, but I've never used them.

Yes.
It's a plugin *.dll which is loaded on 3dsmax startup and adds new format support for exporting object. If you really want to write your own export plugin, then better use blender 3d. It's free 3d modeling/animation program, available on Linux/Windows, and plugin will be portable python script. If blender isn't suitable, then use maya. It's API (IMHO) is much better built than the one in 3dsmax.

an object imported in 3ds max and then exported into custom format might have different normals, hierarchy and animation keys might be converted into another format (from matrix to rotate/scale/position and vice versa). But it all should look the same in engine. The writting of export is good in the sense that you won't have to think how to get data you need from limited standart file format.

Well, that might explain why nobody has provided updated format specifications! It just seems nearly unbelievable to me that a company with a product that popular and which has been updated many times... never added new features to their format! Mind boggling! I just assumed "it's gotta be true" cuz it makes sense. Oh well.

I am also very surprised to hear 3DS format sucks so bad! How can such an expensive and popular hunk of software lack so many fundamental capabilities? Aarg!

*.3ds is very old. From what I've heard it comes from the first versions of 3d studio (I think that some of them were even ms-dos based) where it was used for saving scenes. If you are interested in internals, you might want to read 3ds exporter code in maxsdk (was available at least in 3dsmax 6..7), it should describe most of the chunk data types. Or there was format description on the net. You might want to double check if "new format" exists or not, because I wasn't watching if 3ds format changes. However, I doubt that 3dsmax creators will continue to update format this old. And I'm absolutely sure that last time I've checked it (last year - needed to extract light positions, range and attenuation from *.3ds) there were no normals in meshes(smoothing groups only), spots and cameras were yaw/pitch/roll oriented (generally, this is wrong), and there were no skinned animation support in 3ds.

It's just wery old format, it's not software fault. If you need good format, I'd recommend to look at something else.

After letting my mind process your message in a background task while I was "sleeping", one possibility popped up. That perhaps 3DS isn't that lame, but is exactly the opposite. Perhaps it has so many options to let people save information in "any way they want" - that people do so, by accident, ignorance, default-settings, etc. Especially if different rendering algorithms need different information (for different purposes, or to hide different [lame] feature-sets), people might save without normals (cuz their software doesn't support them) or any other combination of features.

Now personally, that would be a revolting way to do things in my opinion, but nobody ever listens to me (mostly cuz nobody ever asks me (maybe cuz I tend to live places like phobos and atacama and galaxies far, far away, and don't join, and usually don't say anything unless I want help - or answer a question when I am in a forum to get help). I hate the notion of throwing away information that might become useful or valuable or crucial at some later time. But hey, lots of software has lame ways of doing things.

Let me get a couple things straight. 3DS max still is (or was until very recently) a top-tier 3D object design/create tool - and has been popular for over a decade. And the 3DS format is their main format. Or is that wrong?

That's wrong. Their main format is *.max (at least since version 4, current version is 9). 3ds max saves scenes in *.max files and offers ability to export scene into 3ds. *.max is much more complicated, because it stores all modifiers, plugin data, topology, etc. If you want it, look into 3dsmax sdk, it contains description how 3dsmax works and stores data internally, it's very complicated and completely unlike *.3ds scene. Basically if export complex (with Nurbs, vertex animation, booleans, photon shaders and procedural materials) *.max scene in 3ds and import it back, you will lose 90% of data. That's why people write their own exporters.

Okay, that explains a lot. Let me guess... The .max format is not defined in public either. Right? Have people reverse-engineered it and written importers, or published the format?

It also emphasizes the idea that writing an exporter for a tool like 3DS max (or anything that knows how to import lots of formats AND lets you write exporters for your own engine/format) seems like a plausible approach.

I guess it also makes collada potentially more interesting, though I have a personal distaste for XML (probably because I invented and wrote something massively better for my ICE technologies). Even so, if I have my head around this issue well enough (which I might not), collada may be the best alternative. It does seem to include advanced features, and is open-ended (can support any feature anyone concocts), and it also inherently supports letting programs ignore any information they cannot comprehend or process.

Thanks for straightening me out on that. I have an absolutely terrible memory, but I'm still guessing I didn't know that about .3ds and .max before.