  Virtual Reality | 
Posted - 4/25/2005 11:10:13 AM | These last 2 weeks have been pretty tough due to a deadline at work (VRcontext, a virtual reality company), but it's now over. I've created with 2 other developers a presentation (non interactive video) of an offshore platform incident. To generate it we've made a real-time demo which we then recorded at a constant framerate (24 fps). Some screens of this video can be seen here (click to view in full size):
 
 
 
On the tech side, i've implemented the scripts and the lighting effects (there's around 125 per-pixel omni lights in that scene), plus some special fx (lightning, 3D sound, shaders, etc.. ). We are pretty happy of the result, although the code is dirty f-ugly. But heh, when you've got deadlines, you've got no time to make nice code. Now that the stress is over, we'll take some time to clean a few things up.
Some features:
- everything is animated (sea, clouds, lighting, wheather, day/night cycle, crane, helicopter, boat moving with waves, etc..)
- shadow maps + per-pixel lighting, but no normal mapping :(
- procedural sea animated with noise (similar to the Gamasutra article).
- reflections, refractions, underwater effects (not shown here)
- 3D sound using OpenAL
- runs at 15-20 fps on a Radeon 9600/9700, bottleneck is in shading/fillrate
My space engine hasn't advanced much since the last time. I've been experimenting with input/output completion ports under Windows. Looking good so far.
| |
| Networking stress test | |
Posted - 4/10/2005 7:28:23 AM | I started a network stress test, and it doesn't look too good.
At around 200 connections, my CPU usage reaches 100%. What's weird is that the server process itself "only" takes 20%. The remaining 80% are in the "SYSTEM" process. I have no idea why. At first i thought i was transfering too much data, but no. Don't tell me that 2000 packets of 50 bytes each can bring Windows XP to its knees.
I profiled the code, it seems 60% of the CPU time is spent in a kernel module called "amdk8.sys" in an unknown function. Then around 8% in "hal.dll", in a function called "HalMakeBeep". Now that's really weird. I don't hear any beep, and i'm not playing any sound.. Around 10% in various functions of "fwdrv.sys". The rest in my code. Huh ?
If anybody has suggestions, or knows what these modules do ("amdk8.sys, hal.dll and fwdrv.sys")...
| |
| More on the solar system simulator | |
Posted - 4/7/2005 4:35:26 PM | Screenshot time.. but you're warned.. i've been concentrating on the simulation, not the graphics.. yet.
This is an ugly view of Jupiter, with its biggest moon, Ganymede. The dark gray grid in the background is the sun plane. The light gray lines are vectors pointing to the other Jupiter moons.
I've optimized a bit the bandwidth usage of the server; it's now consuming from 150 bytes/second for a few planets in view (ex.: in the Earth neighborhood), up to 500 bytes/second in complex places (Saturn, Jupiter), due to the amount of moons to refresh.
I've fixed some major bugs in the packet positions interpolation (the planets were not moving smoothly. At first i thought it was due to packets loss, but no.. simply some bugs in the code :)). Another major fix was that i forgot to convert some vectors from 32-bits floats to 64-bits floats in some parts of the code, which didn't help either..
It is now pretty much perfect. Real dimensions and scales are used, and i can fly to any planet, and no longer have precision problems, making the planets or the camera randomly jump on short distances.
Since our graphics cards only support 32-bits precision, i use a trick to be able to render planets many A.U.s away from the origin: translations are calculated in 64 bits and relative to the camera (ie. i do "as if" the camera was always at (0, 0, 0)). I have to tweak the transformation matrixes for each object and each frame, but it's well worth it.
I must say, it's kind of magic to think that i've got the full solar system simulation (with code for other procedural systems already in), and working in network, with extremely low bandwidth usage.
I have a game project in mind since many months, but nothing official yet. I'm waiting to have the engine completed before starting it.
| |
| The "Moons" case | |
Posted - 4/7/2005 4:48:23 AM | I just discovered that, even if the simulation was globally correct, the moons in particular were not. They're moving 500 times too fast compared to their real velocity.
I didn't spot the problem first because the orbits are correct. I have in my code a function which, given a time in days, returns me the position of the planet (or moon) on its orbit. Making this function was no easy task, but after spending many days on the net and studying celestial motions, i thought i got it right.
Well..no. Specifically, in that function, there was a hard-coded parameter (the mean angle the body traverses each day around its parent) which i found on a formula over the net, which is only valid for bodies rotating around the sun. In case of moons, you have a planet rotating around another planet. Hence the parameter was incorrect.
I fixed it by calculating it with this algorithm:
1. Calculating the length of the orbit (it's an ellipse)
2. Calculating the mean velocity (it's dependant of the distance and the mass of the parent)
3. Dividing the two => this is the period (amount of days it takes to make a 360° rotation around the parent).
4. Dividing 360° by the period => gives the angle the body traverses each day.
I found that there is no real mathematical solution to the length of an ellipse, only approximations. But fortunately in most cases, the orbits are near circular, so the approximation is good.
After that, i made a test to see if the Moon was correctly rotating around the Earth in 27.8 days, and it was. Yipeee!
| |
| Networking and planet simulator | |
Posted - 4/5/2005 6:11:09 PM | Haven't posted any update since some time.. sorry.
I haven't been idle though. I've been coding pretty intensively these last weeks, although it's only the top of the iceberg. I have started the client / server implementation of my solar system simulator, and today, got the first "good" results.
I am simulating the complete solar system (OUR solar system), with approximately 50 bodies, all correctly orbiting around each other. The simulation is done on the server, and the rendering on the client.
I was a bit worried about the amount of bandwidth usage required to make this little world run smoothly, but finally it's going very well. Assuming 1 update packet per second and per body, each packet being around 50 bytes (positions are transfered as doubles. Floats don't have enough internal precision), i only consume 3.5 KB per second.
Optimizations are not in yet. In particular, the amount of updates per second will be dependant on many factors, like:
- the velocity of the body: Jupiter is rather slow to rotate around the Sun, in comparison of the Moon around the Earth. For the moon, 1 update/sec is pretty right. I think i might get away with 1 update/10 secs for Jupiter, or other "slow" planets/moons.
- the distance at which the camera is from the body: i don't need 10 updates per second to display a planet of 1000 Km displayed at 40 A.U.
- finally, extremely small bodies (<1 pixel) do not need any update at all, since they are "culled" server-side.
You might be surprized about the "1 update per second" only, but planets do move pretty slowly and i implemented client side prediction of the entities movement. It's only a linear interpolation but it works well at the moment. I will improve it later. For the planets.. 1 update per second looks like perfect. You'd never believe it's running on a server.
The clustering system is in. This is basically a data structure heavily optimized to quickly query what entities are in a radius around another entity. This allows the server to determine, given a body/planet, which clients can see it. But i need to stress test it.
The networking component becomes mature. I recently added a lot of functionnality: multithreading, low latency, low CPU usage, low amount of temporary copies, automatic disconnections, automatic latency/ping determination, implements RDP (reliable UDP, but with a reliability system that can be set per-packet), that kind of stuff..
In the next days i'll do some stress tests and consolidate the net code.
| |
|
| S | M | T | W | T | F | S | | | | | | 1 | 2 | 3 | 4 | | 6 | | 8 | 9 | | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | | 26 | 27 | 28 | 29 | 30 | | | | | | | |
OPTIONS
Track this Journal
ARCHIVES
October, 2009
August, 2009
July, 2009
May, 2009
April, 2009
March, 2009
February, 2009
January, 2009
November, 2008
October, 2008
July, 2008
June, 2008
May, 2008
April, 2008
March, 2008
January, 2008
December, 2007
November, 2007
October, 2007
September, 2007
August, 2007
July, 2007
June, 2007
May, 2007
April, 2007
March, 2007
February, 2007
January, 2007
December, 2006
November, 2006
October, 2006
September, 2006
August, 2006
July, 2006
June, 2006
May, 2006
April, 2006
March, 2006
February, 2006
January, 2006
December, 2005
November, 2005
October, 2005
September, 2005
August, 2005
July, 2005
June, 2005
May, 2005
April, 2005
March, 2005
February, 2005
January, 2005
December, 2004
October, 2004
September, 2004
August, 2004
|
