More pages: 1 2 3 4
Monday, December 12, 2005 | Permalink
Some of you may remember my old GameEngine
demo from 2002. Occasionally I get people asking me to do something like that again. I started working on this quite a long time ago, but the project has been more or less idle for most of the time. But I recently got over my laziness and actually finished this thing.
So here you go. It's a bit larger demo than usual, but IMO, a lot better than usual as well. It features a large map, you can do cool stuff like wall-jumps, dodging, rocket-jumps etc.
There's also sound and some background music for a change.
Sunday, January 1, 2006
Great work Humus! Just add your HDR demo code here, and this'd really rock! I love what you've done with the game engine. It has the same feel as UT:GOTY.
Also... I've got a 9600XT. I think your demo is having the same problem as NFS:MW with the shadows, they don't look the way they should, they're jagged! I'm using the official 5.13's, if that helps. I heard that this problem appears when using an nvidia technique for doing shadows, that ati cards don't fully support. Is there a solution for this?, like, blurring the shadows, or filtering them? 'Cause all of your old demos that used the same shadows don't have that problem, they're perfectly fine! (I don't really know what I'm saying... I may be talking shiat, but I'm sure you get the idea.)
Here they are fine:
I've noticed that the shadows don't get rendered well when they come from an oblicuous surface, or thing, like in the picture above.
Again, maybe my drivers aren't configured well... or something in my system is wrong. Excuse me if that's the case.
Looking forward to the next version of the engine, and the coming demos!
Monday, January 2, 2006
To Dr. Vodka:
The GameEngine2 uses shadow maps, and the jagged
edges are expected. I have an nVidia card and I
see the exact same thing. I would assume Humus
uses ATI for developing anyway (as he works for
But i agree...even a simple neighbouring pixel
blur filter will do the world of good. But its
still an amazing demo!! I cant wait to see what
he does with it next (HDR etc).
Monday, January 2, 2006
Thanks for the info. I was wrong. Sorry for all that unnecessary complaining.
Looking forward to your next demos!
Saturday, January 7, 2006
I get this error ever since I updated my Catalyst to 5.13
It ran before I updated my video drivers, but now it crashes on open!
Sunday, January 15, 2006
Looks nice, but the specularity is way, way overdone on everything. Clipping issues everywhere, but I'm assuming that's not what you're concearned with really. Volume light kill fps quite badly and look chees.
I'd say try doing lightmaps, and perhaps have an option to render lightmaps at a user-set quality at start, and cache it by default but give the option to overwrite (say if you want to render at some super sexy quality for 20 min later on) or maybe just include a nicely render lightmap with the download, might be worth bloating it.
Saturday, March 4, 2006
Humus, 10nx for great and technically amazed
Sorry, ) i dont understand you visibility precalculation tech.
As i see, in first step you build the level bsp. In each leaf
of bsp you keep one solid triangle. after that you find the list
of all cubes points, inside the bsp leaves. Further, for each
cube you test all it points with each other points of other cubes.
Vis (cube-to-cube)criterion: if all point-to-point rays are intersected
with bsp triangle, the dest cube invisible, othervise - visible.
It all right?
Sunday, March 12, 2006
The BSP is only used for collision detection and for the visibility precomputations. It's not part of any rendering code. But basically what you said is right, if all rays intersect any triangle in the BSP, then the cube is invisible, otherwise it's visible.
Monday, April 24, 2006
Forgive my late comment on this great demo
I was interested how you did the omnidirectoral shadow mapping. Obviously it had to be cube maps or dual paraboloids. Cube maps, however, don't support depth maps to my knowledge.
From what I understood, you write the length of the light vector to a RBBA8 colour cubemap, and read the x coordinate in the pixel shader. At this point, it gets beyond my understanding. This is actually a 8bit depth value? 8bit depth?
Also, the shadow calculation atten *= float(dot(lVec, lVec) < shadow * shadow); is beyond my understanding. dot(lVec, lVec) == 1 for all values, and shadow*shadow is always less than 1 (unless distance was infinite), so this expression is equal to atten=0.0;? That can't be.
What is my mistake? I mean, it obviously *works* (as can be seen), but I am unable to understand why...
Thanks for your answer
More pages: 1 2 3 4