Not much happening

Note : As with the last entry, this is not about programming, so skip if you came for programming information.

So as told in my last post I got that new shiny GeForce 6800 and I decided to play some newer games and replay some of the recent ones with the higher details I can now set. Sad thing is that I have almost no free time due to personal reasons, so it’s about 1 or 2 hours of spare time a day in the end. And so I don’t think that I’ll do programming within the next few days (which also may affect posting frequency on this blog).

As far as the games go, I tried Doom3 (and it’s expansion) and it now runs smooth at 1280×1024 with 4xAA/8xAF and just looks gorgeous on my 22″ monitor. In D3D the performance difference is big, but in OpenGL it’s huge, as NVidia is more comitted to OpenGL than ATI. I’m really impressed and I didn’t think that the difference would be so big.

And one thing I also do whenever I get a new graphics card is to test out my recent programmed stuff. And well, there was only one older application (which used glSlang, shadow volumes and occlusion queries) that didn’t work as expected (shadows were not visible), but all my other stuff is working like it should. So no bug-hunting in my rendering code for my newer stuff like the NewtonPlayGround, and I’m rather glad about that.

Last but not least I’m also kind of happy to be back at NVidia’s drivers. Though ATI has improved on that field since I initially bought my Radeon 9700, I never was really happy about the Catalyst Drivers. Just recently I was rather upset that I had to use go back three driver releases in order to play the Dawn of War – Addon without heavy stuttering, but those drivers had problems with F.E.A.R. And the current NVidia driver (which may also have problems, but I didn’t came across any) plays all my current games and applications without any hassles.

Not much happening

It’s here

Note : No programming news in this item, so if you don’t wanna know about my new gfx-cards, skip this post.

As usual, Amazon was lighting fast with their delivery. The mail that my new graphics card was dispatched arrived yesterday in the late evening and the card was already here this morning. Why I order hardware at Amazon? Because getting any of the GeForce 6800 cards for AGP is almost impossible now. I’ve tried all the hardware internet shops I know, but they either had no card or the cards in their lists were out-of-stock. I guess vendors are now abandoning AGP (no wonder). So at Amazon I found the Leadtek A400 TDH-256, which is a vanilla GeForce 6800 (12 Pipes, 5 vertex shaders) but with 256 MBytes of memory (usually, vanilla 6800 has only 128 MBytes) for just 195€ (and Amazon don’t take money for shipping orders above 20€s).

After taking out my Radeon and cleaning the PC from dust (which I do all two months or so), I installed the new card. It’s much heavier than the old card and also much bigger (longer), but no problem with my Chieftec case (spending some more money on a good case is always a good thing). See the shot on the left for a comparison. The cooler on the LeadTek is very heavy and also bends around the back of the card, but a big cooler usually means that it’s also silent and that’s the case. It’s a tad louder than the one on the Radeon, but not by much.

And now on to the more technical details of the card :
The GPU on that card is not a NV40, but rather an NV48 which seems to be an shrinked (and therefore cheaper) NV40 (which also means that it should run cooler). It has 12 pipelines and 5 vertex shaders, so it’s not as fast as a 6800GT. I first hoped to unlock them all, but enabling the other 4 pipelines gives rendering errors, so they’re sadly not working. The additional vertex shader on the other hand is, so the card now has all 6 vertex shaders enabled. The clock speeds are 325 Mhz for the core and 700 Mhz (DDR) for the memory, which also is below a 6800GT. But thanks to the massive cooler, it can be overclocked very good and my first testings showed that it’s stable at 400 Mhz for the core and 800 Mhz for the memory. I’m sure there is still room for more, but I’ll try that later on. See the shot on the left for how it looks in my current system, and just look at how big that copper cooler is.

My impression :
Well, if you buy a new videocard every year (or even every 6 months) you usually won’t spot huge differences. But since I replaced a card that I bougth over two years ago, this new one is a real difference. Though the Radeon was still a nice card and ran newer (not the newest) games at enjoyable framerates, this new 6800 tops it in every game. But not only is it faster by a huge amount, it also has some nice features that I wanted to try out, like shader model 3.0 (a big “yes” for loops and branches in GLSL) and all the stuff necessary for HDR. So as soon as I get more time (dunno when, right now it’s very limited) I’ll maybe start to write some shader demos or so again (this time with moving stuff thanks to Newton).

It’s here

Follow up to the last post (and more)

So I finally implemented the new DirectX 3D file format (I mentioned in the last posting, the terrain and vehicle in the screenshot are loaded from .X files) into the NewtonPlayGround. It wasn’t really much work and I also did some more additions to the loader. It now loads textures into a global texture pool, which saves much memory when you have several meshes with the same texture in one scene (e.g. a stack of the same textured boxes).
That means that I have now a format with correct normals to use in my NewtonPlayGround and I’ll start on converting all the models (vehicles, terrains, meshes, etc.) to .X (as long as I made them, or have a version with correct normals of them) so that they all look correct in the final version of the NewtonPlayGround. And one thing that also needs correct normals to look like it should is the cel-shading mode. With the 3DS models it (depending on the model) didn’t give correct normals, not it gives.

Second change on the NewtonPlayGround is, that shadows now are translucent (see the screenshot too). This makes a big change, as the pitch-black shadows looked unnatural. It’s not a big change in terms of programming, but it makes a big difference. Though there still are some minor visual problems, e.g. where the gouraud shading of OpenGL would produce darker fragments than the shadow, but it’s nothing that can’t be overcome.

That’s it in terms of programming. On another note I recently decided to put my good’ol Radeon 9700 in retirement (after 2 1/2 years). I ordered a Leadtek GeForce 6800 with 256 MBytes of memory (for only 195€). I’ll give more info on why and about the new card when I receive it.

Follow up to the last post (and more)

Switching formats

So I’m doing 3D coding for quite some time now (over 6 years afair, at least with OpenGL) and the only 3D file format I’ve used in all those years was the 3DS – format, which is still widely used (due to the fact that almost every 3D modeller can export/import it and there are plenty of loader) but by nowadays standards totally out-dated.

And due to it’s age this format has some drawbacks that recently made me want to get rid of it. The 8.3 file-naming convention for textures is something I can live with, and the 65k vertices limit per mesh too (if a mesh get’s too big, you can easily split it). But one thing I always hated was the fact that the 3DS format doesn’t store normals and also has no way of saving multiple texture coordinates per vertex. Especially the first one is something that annoyed me, and even when computing normals yourself with the use of the stored smoothing groups, you usually won’t get the same normals as in your 3D modeller, and depending on the mesh it sometimes still looks totally wrong.

So yesterday I finally (one of the main reasons for using 3DS for so long : Pure lazyness, writing an importer for a full 3D format is neither simple nor very interesting, and Noeska’s 3DS loder is very mature and easy to use) decided to go for another format.

My first idea was to create a custom format, cause that would making coding a loader very easy and I would then just write a custom exporter. But after thinking a bit more about this, I dropped the idea. Why? Because for applications like the NewtonPlayGround (where I also want to use a new file format), where the user can use his own 3D models, it would’ve meant that I had to give out the exporter. That’s no problem for me, but since different people use different 3D modellers, they’d only be able to create own models when they own the 3D package I wrote the exporter for. So that was the “big no” that stopped me from creating an own 3D file format.

The second idea (and the one I finally went for) was to use an already existing 3D file format that is modern and has all the stuff that one would need for modern 3D applications. So I looked at different file formats, and the one that suited me most was the DirectX file format (.X) in it’s ASCII form (I may add loading of the binary version later on). It’s architecture- and context-free, so that it doesn’t matter what API you use it with. The only drawback : there is no (at least I didn’t found one) loader for that format so that one can use it with OpenGL (D3D has built-in functions for loading .X files).
But after looking at how the ASCII-version of an .X file looks I sat down and started to write my own loader for ASCII .X files. And after some hours it can now load at least the basic stuff (meshes with all their properties, materials, etc.) and I finally (as seen in the screenshot) have the same normals in my apps as the ones I can “see” in my 3D modeller.

Switching formats

Porting the NewtonPlayGround

Porting small demos (like the SDL-Newton demos) is something trivial, but porting such a big application like the NewtonPlayGround is a rather hard and also time-consuming task, so I’ll have to put some thoughts into this before making decissions that I later on may regret. Porting it to other OS’es than Win32 was initially not on my list, but Dominique Louis pointed out that I should use SDL to start with porting, but sadly that’s not the only thing that needs to be done. So here is a list of the most important things I’ll have to do when porting it to Linux (maybe even MacOS, but I have no Mac around) :

  • Display and Windowhandling (minor)
    Straight-forward. Like with some of my other demos/apss I’d go for SDL. Changing from my current way of window handling to using SDL should be very easy.
  • XML (major)
    This would be a big amount of work. NewtonPlayGround uses the XML-components that are offered by Delphi (from Pro and up), so I’d have to replace them when I want to port it to FPC (Lazarus). The only real alternative seems to be the SmallXML-stuff from the JEDI-VCL, but I don’t know if it works with Lazarus. If that’s the case, it’s hopefully easy to replace my current XML loading and saving code (which should be hundreds of lines of code) with SmallXML. I’ll have to see how this works out.
  • User Interface (major)
    This should give me the biggest headache of all the stuff that has to be done when porting the NewtonPlayGround. Up to now the application has a dozen different dialogs, some of which are simple (like the about dialog) and some of which are rather complex (like the one for creating bodies) and include dozens of different components. The VCL is one of Delphi’s biggest strength, so I used it for creating all the nifty and complicated dialogs, but the VCL (please count Kylix out, I won’t use it, Borland isn’t doing anything with it anymore, so CLX is no choice) is windows-only.
    So I would need a good replacement for the VCL which works on all the platforms the NewtonPlayGround should run on. Dominique Louis pointed me to SDLControls, but I’m not sure if it’s sufficient for my needs. It’s nothing official (some personal project) and it also lacks some components I need. Another choice would be to create an OpenGL user interface myself, and I already have something I created for a gameproject of mine. It’s rather advanced but also lacks many components I would need, so this would mean additional time to implement those missing controls.
    But no matter what way I choose, changing the user interface would be the biggest and most time-consuming part of all the porting.

So as one can see, porting the NewtonPlayGround would take many hours (days, weeks, who knows) of my very limited spare-time. So unless I don’t “gain” anything from it, I don’t think that I’ll be doing it. So if there are enough requests for a port to Linux (or even MacOS) I’ll consider this again, otherwise the NewtonPlayGround will stay Windows-only. And please don’t ask why I haven’t developed it with cross-platform in mind from the beginning, cause when I started out with it I neither thought it would become so popular and complex, nor was there a Linux/Mac-version of the Newton Physics Engine.

Porting the NewtonPlayGround

Springtime…

…is gladly over as I prefer winter. But the title is there to describe the latest addition to the NewtonPlayGround, namely Springs. Implementing them was rather easy, and I took my informations on springforces from this article. Right now there are only unlimited springs in, but I also plan on implementing limited springs. If you’re interested, you can see a video of the newly added springs here (1.75 MBytes, WMV). Depending on how you use them they give some nice, unpredictable (at least for humans) results that make for some great fun.

One thing I noticed while adding this new feature (as with most of the newly added features, I first implement them into a simple testing application and port them later on to the PlayGround, this makes finding error easier) is how big the NewtonPlayGround actually grew over the last months. At first I started it out as another Newton-Demo, but it has now grown into a huge application with almost unlimited functionality. Right now, only the main source is already over 10 thousand lines of code, not counting stuff I’m reusing from older projects (like code for shadow volumes, matrices and vectors, loaders, and so on).
And though I recently removed all memory leaks (thanks to FastMM4) and sticked to clean coding-rules I’m wondering about the bugs users will find once the new version is out. Since there is so many stuff one can do with the NewtonPlayGround it’s impossible for me to test out everything. But I just hope it won’t get too bad after release.

Springtime…

Cel Shading

Some time back I already did two demos on cel-shading, which is an easy to implement technique to give a whole scene a comic-like look. It’s especially good-looking on scenes that aren’t too complex and incoroprate mainly basic primitives. So I decided to put this render mode into the NewtonPlayGround :

As you can see when comparing the two shots (Well, in case you didn’t realize it : the left one has cel-shading on, the right one not) cel-shading really gives that scene some unique and interesting touch. I also add some over-brigthness when using cel-shading, as it only really looks good with bright and vibrant colors.

But since that isn’t the case for all scenes (like e.g. a scene with a textured terrain and vehicles and so on) I’ll make it toggable. Either with a key-press or as a scene-setting that get’s stored into the saved XML-file and also is then set upon loading a scene. So the creator of the scene has the choice on wether to use cel-shading for his scene or not.

Besides this new addition I also finally got around writting the manual for NewtonPlayGround. I got some chapters done and hopefully the structure I choosed will fit people that don’t know much about the PlayGround and people that exactly know what to look at. But I must admit that it’s really boring writing a somewhat bigger manual (a small readme for some game is written fast, but not a manual for a bigger application).

Cel Shading