| Cyborg: | Hey Ken, I checked out your voxel engine screenshots today. Are those lighting effects realtime or precalculated?
|
| Ken: | I have both. The realtime lighting is obviously slower and more limited. None of the screen shots show the realtime lighting.
|
| Cyborg: | Would the realtime lighting be the standard spherical light entity a lá Quake?
|
| Ken: | No, it casts true shadows, and diminishes with 1 over r (that's radius for those of you not familiar with your maths - Cyborg) squared. You can do that with voxels.
|
| Cyborg: | Sweet.
|
| Ken: | Voxels would be the perfect 3D engine if only I could get more memory and speed.
|
| Cyborg: | Is the voxel engine compiled for DOS 4GW still?
|
| Ken: | Yes. I know how to port it to windows, but I still prefer doing my development in DOS
|
| Cyborg: | Have you considered trying to put in features like alpha blending to emulate 3D cards?
|
| Ken: | No.
|
| Cyborg: | Well I ask because looking at the screen shots the voxels are kinda chunky.
|
| Ken: | Yes, they are.
|
| Cyborg: | So that doesn't bother you at all then?
|
| Ken: | Of course it does, but there isn't much I can do about it. The more detail I put in there, the slower the engine will run. Voxels aren't a complete waste of time - unlike polygons, it's very easy to modify the map, for example, you can shoot a rocket at a wall, and you can explode a sphere (or any shape) out of it and have it part of the permanent board map.
|
| Cyborg: | What about having a system whereby the size of the voxels used to render the image increases with distance? So you get a sharper image for closer objects?
|
| Ken: | Oh, if you mean mip-mapping, yes I plan to do that. It's a pain to do, but I will definitely get it in there.
|
| Cyborg: | I think voxel engines are definitely worthwhile, but the 3D industry is obsessed with polygons
|
| Ken: | Still, I can't make the close voxels too small because they already take up too much memory. Yeah, down with the industry!
|
| Cyborg: | Heh, but it's true though, if you don't use polygons no one wants to know
|
| Ken: | I hope voxels will rule the world someday, since they are so much easier to work with.
|
| Cyborg: | Why not use spheres for your voxels though? You'd get a 'smoother' look
|
| Ken: | It was enough of a stretch to get them to look like cubes
|
| Cyborg: | Well, circles then? That's a bit easier.
|
| Ken: | I actually ray trace the map in a way similar to a Comanche engine, so it would be impossible to use spheres. Spheres and circles wouldn't solve the problem of detail. If I wanted a smoother look, I suppose I could totally re-write the engine and use a marching cubes algorithm.
|
| Cyborg: | What on earth is a marching cubes algorithm?
|
| Ken: | It's a way of converting a grid of cubes into smoother looking polygons.
|
| Cyborg: | Ah.
|
| Ken: | It would probably kill the speed of my engine, but it would look nice
|
| Cyborg: | What sort of minimum spec are you aiming at then?
|
| Ken: | Probably something like a Pentium III-500. It actually doesn't run that much slower on it, since the bottleneck is memory (and all Pentiums these days are either 100Mhz or 133Mhz memory bus speed).
|
| Cyborg: | How much memory does your engine like to have then? A lot of people have 128Mb or more after all.
|
| Ken: | I have 256MB on my PIII 933, but it'll only require 64MB. If I need to make bigger maps, then I'll write a disk caching system.
|
| Cyborg: | Have you thought much about 'natural' lighting? There aren't any game engines which really convey a sense of natural light.
|
| Ken: | You mean multiple bounces?
|
| Cyborg: | Basically. For instance, having a sun like object light that voxel room through a window. That would be impressive, especially if it were over time. So you could have day/night time frames in a single level.
|
| Ken: | That's certainly possible. Right now, I only know how to do point sources with no bounces quickly.
|
| Cyborg: | I remember 3DR saying they were going to have this type of lighting in Prey... but then not much happening there.
|
| Ken: | That's because they bragged before they knew it was a difficult problem
|
| Cyborg: | I wouldn't say it's the only problem Prey has by a long shot. Disappointing to say the least.
|
| Ken: | Their problem is the whole team left and George only describes it as a "minor" speed bump
|
| Cyborg: | heh. Anyway, how do you handle the rendered environment and the physical environment, that is to say, having entities in. Or have you not gotten that far yet?
|
| Ken: | You mean sprites?
|
| Cyborg: | Well, in the strict sense yes (that doesn't mean flat images people - Cyborg).
|
| Ken: | I haven't implemented it yet, but I plan to make sprites part of the board format itself. This way, I'll be able to have them affect the lighting
|
| Cyborg: | Then might I make a suggestion? It'd probably kill the memory but it would be cool if you gave each voxel some physical attributes, like density, elasticity etc... then the entities that inhabit the world would interact with the world in a very realistic way.
|
| Ken: | If I do that, it won't be at the voxel level. I might do something like that for each limb (or bone). I could still do something like that at the voxel level since I use 32-bit color and I'm not using the 4th byte
|
| Cyborg: | So the world objects have geometric descriptions with a voxel mapping on top of them?
|
| Ken: | That's what I plan, but it could change.
|
| Cyborg: | So if your world is described by geometry, could I do something like create an exponentially decaying sine wave and apply that to objects to create ripples?
|
| Ken: | You could do ripples anywhere I suppose, but I meant to say that only the sprites would have geometric descriptions behind them. It would be a neat thing to add to my editor
|
| Cyborg: | Ah. Okay. I'm thinking along the line of producing seriously nice water effects.
|
| Ken: | That can be done, but it would be slow because it requires constant manipulation to the board map. But that is a nice effect to have, so I'll try to think of something to make is feasible
|
| Cyborg: | A trick I use with using sprites for effects in Build is to only have them exist at a certain distance of proximity to the player. So if the water surface was made of entities that might be more feasible?
|
| Ken: | Well that's one trick, but it could still be a problem if you have a large body of water. Entities wouldn't help if I plan to make them part of the board format itself
|
| Cyborg: | Whilst talking of water do you have transparency yet?
|
| Ken: | No.
|
| Cyborg: | I'm guessing no reflection either then too. If you could have reflection/refraction indexes for surfaces that would be quite superb. Seeing reflections in water and seeing through it as it should be.
|
| Ken: | It would be nice, but it's not going to happen. voxels are an uphill battle in every respect
|
| Cyborg: | Why can't you do that then?
|
| Ken: | The problem is that every small modification I make to my inner loop destroys the frame rate
|
| Cyborg: | Well you could always provide rendering options.
|
| Ken: | I can't do reflections because it would require me to do a lot of extra ray-tracing that I can't afford.
|
| Cyborg: | That's a shame.
|
| Ken: | The only way to do something like that is with a severe limitation - like the reflective surface has to be perfectly flat and parallel to the ground.
|
| Cyborg: | Well that would rule out water waves... But some sort of reflection would still be useful.
|
| Ken: | There are always methods that aren't physically correct. Like those spheres they call dynamic lights in Quake
|
| Cyborg: | Well, the way I see it, if it's a game the player is not a spectator so you can get away with imperfections.
|
| Ken: | I'm more interested in things that can make game fun rather then eye candy that kills the frame rate. And being able to modify the board in any way you want is a pretty nice thing to have.
|
| Cyborg: | Sure is, you could have moving sand dunes... That would be quite interesting... But eye candy never hurt anyone : )
|
| Ken: | Yeah, just the fps : )
|
| Cyborg: | Software writers tend to rely on PC improvements rather than improve their code.
|
| Ken: | Yes, when they don't know how to optimize. My voxel engine has a lot of tricks in there to make it fast, but I guess nobody will notice them (at least until they try to make their own).
|
| Cyborg: | Well I know you love making efficient code from the stuff I've seen at your site.
|
| Ken: | Thank you.
|
| Cyborg: | If anything I think an RTS would work well with your proposed technology.
|
| Ken: | I suppose. Here are some ideas I had that might work: Dig Dug 3D and Worms 3D
|
| Cyborg: | Worms 3D? Landscape you can blow up? That's what I was thinking for the RTS idea.
|
| Ken: | Yes, exactly. Are you familiar with Team17's game Worms?
|
| Cyborg: | Yep, although Scorched Earth and Gorillas have more appeal for me : )
|
| Ken: | Those are older games, right?
|
| Cyborg: | Yes, Gorillas is this QBasic thing, and scorched earth had tanks with ridiculously powerful weapons that would wipe out everyone in one go. I don't think I'm familiar with Dig Dug.
|
| Ken: | It's a really old game from the early 80's. You did digging underground, then when you get exposed to enemies, you expand them with your pump to destroy them.
|
| Cyborg: | Lemmings would work well in voxel landscape... more closely related to the original game than the 3D one.
|
| Ken: | That 3D one used a terrible engine, had even more drawing bugs than Build : )
|
| Cyborg: | Build was pretty good really. Ever play SkyNet? I gave that back it had this horrible effect like static going across the screen. It ruined a reasonable game with a very buggy renderer.
|
| Ken: | Never played SkyNet.
|
| Cyborg: | Your voxel editor... how does it work thus far then?
|
| Ken: | Right now, the map is 1024*1024*256 (high). You can insert or delete boxes, spheres, ellipsoids, and cylinders. I also have a sector-like object, and a lathe tool for those cool looking donuts, etc. I also have a "flash" function. You press "F" and everything around you that you can see gets brighter
|
| Cyborg: | Is it a brush like system?
|
| Ken: | I guess. You can move things around and change things (for example, xyz position, color, and radius) until you're satisfied.
|
| Cyborg: | Do you have negative brushes? If not add them!
|
| Ken: | Do you just mean cutting things out of the map instead of adding them? Yes, I have that.
|
| Cyborg: | Yes but not just cutting, you have objects which you can move around but where they intersect with positive brushes the net result is empty space. So you don't make permanent changes to a positive brush...
|
| Ken: | You mean like an XOR?
|
| Cyborg: | Yes basically.
|
| Ken: | No, I don't have that
|
| Cyborg: | It's quite useful when editing because you don't have to undo stuff if you messed up a cut. You just alter your negative brush.
|
| Ken: | Or I could support multiple undo...
|
| Cyborg: | Sure could, but what if you change your mind half an hour later after a load of editing? You don't need to store all your previous actions which takes up memory/disk space.
|
| Ken: | True, but an XOR brush would carve out useless areas that you can never see. It wouldn't work because you would lose color information (I only store voxels on the surface).
|
| Cyborg: | But this is the editing process - I know you like to cut away the insides of the voxels (see Ken's other Voxel tools to see what I mean - Cyborg). I only suggest because negative brushes are used by some 3d modeling packages for this reason. It could have uses in game too though.
|
| Ken: | How?
|
| Cyborg: | For non permanent world geometry changes. It would be faster to have a negative brush then try to restore the previous game geometry after it was changed.
|
| Ken: | So in other words XOR old, XOR new instead of Backup, Modify, Restore
|
| Cyborg: | Yep.
|
| Ken: | What if backup & restore were really fast?
|
| Cyborg: | Well, if it were obviously it would be better. But I can't see how storing lots of changes over time would be faster than having a negative sphere brush intersect with a surface and withdraw again. For example.
|
| Ken: | Unfortunately, the XOR thing only works if my voxel format is uncompressed. I don't see how I can temporarily cut out part of the map without having to backup and restore the information. Trust me, it won't work with the way I designed my engine.
|
| Cyborg: | Well I'd certainly not want to argue with you there. I could see it would be more difficult if the voxel information wasn't linear. It might still be a useful tool to use in an editor though.
|
| Ken: | Yes, that can be done, and you are right - it would be useful. But it would be like this: Backup, Xor, Restore.
|
| Cyborg: | This voxel engine does sound like it will be great fun to use.
|
| Ken: | It's something different - that's for sure. Hopefully it'll open up totally new types of games - ones which modify the environment extensively (without precalculations). But unfortunately, there are a lot of things that polygon engines are just better suited for.
|
| Cyborg: | Static fields? Describing an environment in less data? Those would be my guesses.
|
| Ken: | Advantages of polygon engines: Less memory, hardware support, pre-defined modification to the board (like doors or vehicles restricted to a sector).
|
| Cyborg: | Hardware support is the big one.
|
| Ken: | Speed is always nice, but with voxels, things don't slow down too much when you want to do curves. Think about that.
|
| Cyborg: | Yea, it's not really any different to do a curve in a voxel environment than a plain surface because the basic unit is the same.
|
| Ken: | A voxel engine is great for rocks, dirt, etc... A polygon just can't do that well.
|
| Cyborg: | Of course the response by the manufacturers is to increase the polygons/second so game designers just use more polygons to make objects.
|
| Ken: | It's wasteful to make indoor environments with flat walls everywhere in a voxel engine.
|
| Cyborg: | There have been hybrid engines but they've not really taken off, like that Outcast game.
|
| Ken: | Even so, you won't be seeing a rocket blowing a hole into a wall in a polygon engine : -)
|
| Cyborg: | Heh, no, not unless you tell it you want it to be destroyed first.
|
| Ken: | That Outcast game is much simpler in many ways from my engine.
|
| Cyborg: | I've not played it, just read about it. Didn't take my fancy. Please do elaborate though.
|
| Ken: | It only supports one voxel per column. You have to look straight towards the horizon all the time.
|
| Cyborg: | Ah, yes, a bit limiting.
|
| Ken: | They fake room over room with polygons, but it just doesn't look good next to the voxels.
|
| Cyborg: | Well I've only see the carefully chosen promotional shots : -)
|
| Ken: | They do have some nice water effects, but it is a bit buggy and it doesn't make the game any more fun to play.
|
| Cyborg: | Well I'll have to wait and see what sort of animation your voxel engine could apply to water. It would be very nice to see ripples from multiple sources causing interference effects on the surface.
|
| Ken: | Don't count on it.
|
| Cyborg: | It would be possible with your deformable geometry though, if maybe slow. Although having a predefined table of values could speed it up.
|
| Ken: | Maybe I could use environmental mapping for the reflections
|
| Cyborg: | Which would involve..?
|
| Ken: | For each voxel on the water, I would have to estimate a normal vector (perpendicular to the water surface), and with this vector, I could then pick a color directly out of a texture mapped cube or something like that. It's one of those "fake" methods, because it doesn't require a separate raytrace per reflective voxel.
|
| Cyborg: | Sounds reasonable for an approximation. If the water is moving you'll never notice it's not true anyway.
|
| Ken: | Estimating normals can be slow, but a reason I wouldn't do it is that it requires me to test every single voxel whether it is reflective or not. This would slow down the entire engine for an effect that is probably only seen in a small part of the map.
|
| Cyborg: | Could you not apply a test to see if the player is viewing from a close enough proximity? Hence the effect would only be used where it would be noticed.
|
| Ken: | Yes. I would have to duplicate my assembly code : -(
|
| Cyborg: | Have you made coloured lights yet? I'm guessing it wouldn't be too much of a step to only apply lighting increase to one channel, r g or b.
|
| Ken: | That would be easy. Finally a feature I can do!
|
| Cyborg: | Heh, I'm tough to please eh? : -)
|
| Ken: | Yes.
|
| Cyborg: | Does that computer have red text on its screen? Is it readable close up? (Look at the screen shots on Ken's site -Cyborg).
|
| Ken: | It's supposed to say C: \
|
| Cyborg: | I think I can just about make that out from the screen shot. I was just thinking about the possibility of animated 'tiles', perhaps using a routine to make use of bmps to apply colour changes to voxels to get a moving image. I think there's enough room on your wall for one of those big flat screen televisions : -)
|
| Ken: | I only wish it was as easy to animate tiles as it was with the Build engine. With all these difficulties, I have to make a really good game demo to prove that a voxel engine is useful for something.
|
| Cyborg: | Well, some sort of texture mapping routine for your voxels would seem a good start. The screen shots look pretty sweet all the same.
|
| Ken: | Thanks! I was thinking about adding a feature to my editor which allows you to paste a picture onto a wall (preferably the .PNG format).
|
| Cyborg: | Definitely useful, you create the world geometry and then paint it from an image library.
|
| Ken: | Yup. That's the way I'd do it.
|
| Cyborg: | And of course you could use any number of image combinations to paint little variations into the mix.
|
| Ken: | Sure. Since I don't use tiling, there's no limitation to the number of ornaments you could put on the walls.
|
| Cyborg: | Perhaps you could even use a bevel tool to make a flat image 3D.
|
| Ken: | Here's what I was planning: When you load the picture, I show it (translucent) right on the screen. Then you could move around, and when you press the "paint" key, it sticks to the wall (or whatever's behind it) like a paint gun.
|
| Cyborg: | Ah, but what if you just wanted a portion of it? Perhaps a masking system would be useful so you can stop certain areas from accidentally being changed.
|
| Ken: | Perhaps I could have a 3d box in which only voxels inside it could get modified.
|
| Cyborg: | Allow multiple boxes and then the user can mask off pretty much any shape they want.
|
| Ken: | Probably the best thing is to have the map designer select the texture when drawing the geometry in the first place.
|
| Cyborg: | But surely you just get back to square one? If you apply the texture at the start and want to place another one over the top...
|
| Ken: | I suppose I could store the entire editor history. It wouldn't take up too much memory to store (x,y,z,ellipsoid,radius,texture, etc...) It would be fun watching it render too.
|
| Cyborg: | Sounds like a good and fun solution.
|
| Ken: | But it'll get slower and slower over time. And there would be problems if you do any individual voxel editing. It seems like Voxlap5 is more like a 2d paint program than a 3d engine.
|
| Cyborg: | No, it's more a true 3D engine - if you start thinking of voxels in the greek sense of atoms. Best go back to the simple paint gun then and let the user get his images right in the first instance. You'll need a transparency colour. Hmm, maybe you could allow optional 'paint strength', so you could have faint images applies.
|
| Ken: | No problem - .PNG files support an alpha channel. I could add paint strength into the equation as well.
|
| Cyborg: | Oooh, what about controlling each channel individually? R G and B on their own strength?
|
| Ken: | Ok, but how useful is that?
|
| Cyborg: | Well, you never know... You might want to paint an image in a certain shade of colour. So lowering the green and blue alpha would make it red.
|
| Ken: | You're right. It could turn out to be useful. But first things first!
|
| Cyborg: | I've lost track of that, what is first?
|
| Ken: | Painting a .PNG file onto the map, sprites, Also, cleaning up my lighting (we haven't talking about it yet).
|
| Cyborg: | What's this lighting stuff then? The lighting looks fairly accurate from the shots, with shadows and whatnot.
|
| Ken: | My "flash" function has aliasing effects when applying the lighting, so I need to smooth it out afterwards.
|
| Cyborg: | You should make light entities really. Slower but easier to work with.
|
| Ken: | I should.
|
| Cyborg: | Of course you could always render light sources effects permanently to the voxels from the editor once you were satisfied with the lighting. Like a flash but with more precision.
|
| Ken: | If an object moves, the lighting is no longer accurate. I will have to use entities if I want true dynamic lighting. What you described is exactly how I do it now.
|
| Cyborg: | Yes I can see how that would be... kind means that prerendering lighting is pointless.
|