Yeah, that's why I noticed it.PolyVox wrote:I agree this would be really cool and I am planning to try it. Ken silvermans Voxlap engine allows this so it should be possible. It's such an obvious thing to expect that it looks noticably wrong when it doesn't happen. Not sure when I expect to do it though...nikki wrote:Nice! Is it possible to break pieces off the castle and make them be affected by physics too?
I have an idea of a game where there are two (or more) dimensions (as in parallel worlds), where you switch between the dimensions to get to an objective.PolyVox wrote:Cool, will that be GraLL 2? Or you have somehthing different planned...nikki wrote:Nice work! Keep going! It looks like a nice technology to steal for my next game.
Ummm kind of already been done:nikki wrote: I have an idea of a game where there are two (or more) dimensions (as in parallel worlds), where you switch between the dimensions to get to an objective.
For example, there's a wall in dimension A, and its not there in dimension B. So, you switch to dimension B from A to get past it. This can have lots of twists, such as enemies becoming friends in another dimensions, moving platforms not working in other dimensions, places where you can't change dimensions... there are so many possibilities! Maybe you'll even have to shoot a projectile and keep changing dimensions as it goes through a set of walls. The changing of dimensions will be really frequent, even as you're moving, falling, jumping...
But, right now, I'm pretty busy with school, so I'm learning more about shader programming, reading books and other stuff related to game design (art or programming), or even computer programming in general (like design patterns) before actually starting work on the game. That way, I'll be better prepared for it.
I think thats a really cool idea! Have you thought about what style of game it will be? E.g. platformer, first-person, top-down, etc?nikki wrote:I have an idea of a game where there are two (or more) dimensions (as in parallel worlds), where you switch between the dimensions to get to an objective.
For example, there's a wall in dimension A, and its not there in dimension B. So, you switch to dimension B from A to get past it. This can have lots of twists, such as enemies becoming friends in another dimensions, moving platforms not working in other dimensions, places where you can't change dimensions... there are so many possibilities! Maybe you'll even have to shoot a projectile and keep changing dimensions as it goes through a set of walls. The changing of dimensions will be really frequent, even as you're moving, falling, jumping...
That's a really cool concept, though too hard for metwilight17 wrote:Ummm kind of already been done:
http://www.addictinggames.com/shift.html
http://www.addictinggames.com/shift2.html
It's a long way short of what nikki is describing though - for a start it's only 2D and in black-and-white. But it does show how much fun a simple concept can be. I think it will be first-person.PolyVox wrote:I think thats a really cool idea! Have you thought about what style of game it will be? E.g. platformer, first-person, top-down, etc?
True - but don't forget, most of the additional complication was imposed by our target platform. For instance, if you can regenerate the geometry without timeslicing, or simply retain the old geometry until the new geometry is ready, you can do your collision with the geometry rather than the raw voxel data - at which point deforming the lattices makes no difference at all.PolyVox wrote:Hmmm, I see. I can understand why they do that - working with lattice deformations is common in many 3D modeling packages so it was probably more natural to them that sculpting the individual voxels. However, it not something I was really planning to implement because (as you noticed) it gets a lot more complicated.
Yes, I wrote an in-house editor. Your plan does have some drawbacks:What tools were the artists using for making the voxel models and applying the deformations? Presumably something developed in house? I was instead planning to have objects modeled in a standard package, placed into the world, and then voxelized.
Sure you can - just embed an indestructible 'core' lattice within the outer one.But it sounds like your system does have a limitation - presumably you can't have an object which is a different material inside to outside. So you can't blast through a brick wall and find there is earth behind it? Or shoot a concrete statue and discover it has a steel core?
Yeah, you've got a lot more headroom. 32mb isn't much, not when it has to accommodate the whole of the rest of the game graphics and code as wellRegenerating data over multiple frames is also something I have considered but haven't needed yet. I guess I have the advantage that I'm targeting a considereably more powerful machine. There's a lot more speed I can squeeze out of my marching cubes implementation but it may turn out that the bottle neck is in uploading the data to the graphics card.
No, I'm sure your method will be fine - again, you're targeting a far higher spec. The PS2 didn't even have multitexturing, so we had to use vertex lighting (and hence vertex shadowing).Shadowing is a very interesting issue which I haven't addressed yet. But I'm basically planning to use one of the standard approaches (probably shadow maps) and I'm expecting it to 'just work' on fully dynamic scenes. Is this naive? Or were you precomputing the lighting in order to get higher quality or a certain artistic feel?
Don't be afraid to timeslice different jobs differently. I timesliced the geometry regeneration in big chunks, with the recalculation of shadows following at a more leisurely pace. You could easily do the same, and simply 'fade' between the old and new when the new is finished.Actually I have thought about computing the lighting by tracing rays through the voxel data and I think it does have potential. The first article in GPU Gems 3 does a voxel based landscape and uses raytracing in the volume data to compute ambient occlusion. I think it will look nice, but I'm concerned that recomputing the lighting whenever part of the world is destroyed will be too expensive for the CPU.
I do have various ideas for smoothing the models and adding detail via bump/relief mapping, but I accept your point. Though really I think the bigger problem is the lack of control over UV coordinates. I guess the extent to which this matters depends on the type of game it is used in.Peeling wrote:1. Voxelised polygonal models simply won't look like the originals. Even if you use prohibitively high voxel densities, the lighting won't look right because you've only ever got the 90/45 angles of voxel corners to work with.
Well worlds generally won't be animated, with the exception of lifts, doors, etc. These probably should be seperate volume (whether lattices or 'regular' volumes). Other types of movement (swaying, etc) could possibly be emulated in the vertex shader, though of course then the physics is more tricky.Peeling wrote:2. You can't hope to animate models converted in this fashion. Even if you have multiple 'frames' of voxel animation you can't extrapolate damage incurred by one frame across the rest.
Basially I can see the appeal of a lattice based approach in terms of being artist friendly and allowing a good degree of control over the world creation process. But I suspect the resolution of the resulting world will have to be lowerthereby giving less granularity to the destruction which can be achieved.Peeling wrote:It's a lot more work, but creating a proper editor and supporting lattice deformation - including animated lattice deformation - will make it possible for your users to get the absolute most out of the engine.
Thanks again! The technicalities of the project haven't been discussed with many people because it's not a widely used approach. But, when I have discussed it, it's always been productivePeeling wrote:I'm glad to have been of some assistance
Hmm. If I had the code in front of me I could answer that very easily, but I don't. I think the largest permitted individual lattices were about 30x30x20, or 18000 voxels, but most of the time there were a large number of lattices containing substantially fewer.PolyVox wrote:Basially I can see the appeal of a lattice based approach in terms of being artist friendly and allowing a good degree of control over the world creation process. But I suspect the resolution of the resulting world will have to be lowerthereby giving less granularity to the destruction which can be achieved.
I realise you can't say your world was X by Y by Z, but can you give an indication of how many voxels you were using?
Obviously, a non-deformed lattice is just a special case, so if that's what the artist wants he can just use it.That said, I don't see why the two approaches can't coexist in the same engine, so I will think about it for the future. Perhaps my approach could be used for the landscape, etc, and yours for things like buildings. With careful design it should be possible to abstract away the differences in implementation.
I can't remember exactly; I think I was taking a trip down memory lane doing searches for Outcast running on Vista.Btw, how did you find my project? I'm curious as to how widely it's being seen by people in industry. Though the real promotion starts in a few weeks when my website goes live.
There are really two parts to the system. 'PolyVox' is the underlying library which handles the generation of the meshes from the volume data. 'Thermite' is the engine which takes the data from PolyVox and feeds it into Ogre and Bullet.DarkPikmin wrote:Ahh, sweet engine man! one question though, does it still support implementation of additional addons and code? Like say could I modify the PolyVox and Bullet to include a DMM mockup?
Both! The data which comes from the PolyVox library is never turned into an Ogre mesh - it is loaded directly into index/vertex buffers and also sent directly to Bullet. On the other hand, objects within the scene are Ogre meshes and so OgreBullet is used to keep the data synchronised with Bullet.DarkPikmin wrote: Did you use the OgreBullet wrapper for the physics, or did you write your own?
Yep, that's the idea. Probaly some kind of turn base strategy with tanks/artillery. Exact details to be decided. Eventually I'd like to make a Descent-style game with 360 degree freedom of movement and cool destructible environments. Bu we're starting smallyapdakilla wrote:Awesome stuff. are you planning to complete this project into a full game? Could be the next Worms type game. Only in 3D !
The license is GPL. The implementation still needs some work (I've been more concerned with getting the features in for the artist I'm working with to use) but this will stabilise over the next few months. You can take the whole engine as-is, or alternatively the core code for maintaining the volumes and generating the geometry is available as a separate library for integration into your own engine.yapdakilla wrote:Depending on the license and implementation, I think I'm going to try to use it in my FPS project. It would be fun being able to build new entrances..
