Wow thats good news, i've been watching this with great interest for some timePolyVox wrote: The most significant advances is are:
1) The integration of rigid body physics using Bullet. You can dynamically modify the scene while objects bounce around.
2) The (mostly finished) separation from Ogre, allowing the library to be used in non-ogre projects. I'm still using Ogre for the showcase engine, though.
Actually I am expecting to release a new tech demo within a week![]()
Fully Destructible Levels - New website and domain!
-
Entropai
- Kobold
- Posts: 30
- Joined: Fri Jan 19, 2007 10:42 am
-
Jallen
- Halfling
- Posts: 61
- Joined: Sat Dec 29, 2007 8:34 pm
-
PolyVox
- OGRE Contributor

- Posts: 1316
- Joined: Tue Nov 21, 2006 11:28 am
- Location: Groningen, The Netherlands
- x 18
-
PolyVox
- OGRE Contributor

- Posts: 1316
- Joined: Tue Nov 21, 2006 11:28 am
- Location: Groningen, The Netherlands
- x 18
Thanks! But actually a few people have had the crashing probelm - I've never exactly addressed it but so much had changed that maybe it's just disappeared. Or maybe that's wishful thinking...Jallen wrote:It's awesome, but it crashes for me when i dig too deep in to the walls. (8800GT, Athlon64 3500+, 2GB RAM) DX9 Renderer.
Well, let's see if it occurs in the new tech demo when I release it.
-
triton
- Greenskin
- Posts: 138
- Joined: Thu Mar 13, 2008 10:25 pm
- Location: Portugal
-
PolyVox
- OGRE Contributor

- Posts: 1316
- Joined: Tue Nov 21, 2006 11:28 am
- Location: Groningen, The Netherlands
- x 18
*** Update - Rigid Body Physics ***
I have updated the tech demo to show the new integration with Bullet - this allows rigid body physics in a fully destructible environment. The things you might want are:
New Demo:
http://www.david-williams.info/linked_f ... csDemo.zip
Runtime (install if you have a problem running the demo):
http://www.microsoft.com/downloads/deta ... laylang=en
YouTube Video:
http://www.youtube.com/watch?v=qmZrdBBQThk
Higher Quality Video (Encoded with XViD):
http://www.david-williams.info/linked_f ... moXVid.Avi
Screenshot:

I haven't been providing updates on this project as often as I would like but it is still moving ahead. The latest demo shows how both Bullet and Ogre can be updated with new environment data in real time. It's still early in the physics integration stage and I need to make a lot of speed improvements but the potential is definitely there
The project is now really two projects:
PolyVox Library: The underlying library which stores the volume representation of the world and is responsible for generating new meshes when the voxels change. This library is independent of Ogre and the idea is that anyone can integrate it into their own engine.
Thermite Game Engine: An experimental game engine to showcase PolyVox technology by combining it with Ogre and Bullet.
Actually this separation is not quite complete but should be within a few weeks. Note that the code is not easily buildable on either Windows or Linux at the moment (you really have to know what you are doing) but as the separation proceeds and the code gets neater this should change.
Both projects are under the GPL.
Anyway, let me know if you have any questions!
I have updated the tech demo to show the new integration with Bullet - this allows rigid body physics in a fully destructible environment. The things you might want are:
New Demo:
http://www.david-williams.info/linked_f ... csDemo.zip
Runtime (install if you have a problem running the demo):
http://www.microsoft.com/downloads/deta ... laylang=en
YouTube Video:
http://www.youtube.com/watch?v=qmZrdBBQThk
Higher Quality Video (Encoded with XViD):
http://www.david-williams.info/linked_f ... moXVid.Avi
Screenshot:

I haven't been providing updates on this project as often as I would like but it is still moving ahead. The latest demo shows how both Bullet and Ogre can be updated with new environment data in real time. It's still early in the physics integration stage and I need to make a lot of speed improvements but the potential is definitely there
The project is now really two projects:
PolyVox Library: The underlying library which stores the volume representation of the world and is responsible for generating new meshes when the voxels change. This library is independent of Ogre and the idea is that anyone can integrate it into their own engine.
Thermite Game Engine: An experimental game engine to showcase PolyVox technology by combining it with Ogre and Bullet.
Actually this separation is not quite complete but should be within a few weeks. Note that the code is not easily buildable on either Windows or Linux at the moment (you really have to know what you are doing) but as the separation proceeds and the code gets neater this should change.
Both projects are under the GPL.
Anyway, let me know if you have any questions!
Last edited by PolyVox on Tue Jul 07, 2009 9:13 pm, edited 2 times in total.
-
Five_stars
- Gnoblar
- Posts: 22
- Joined: Wed Sep 26, 2007 10:27 am
WOW! (And it's not the name of game
)
Astonishing video and features, of course!
Added 1:
There was small problem with starting up. Archive must be packed into "C:/Thermite/", else programme can't load GL library (Ogre.log
).
Added 2: It's just a small notice.
If I have changed the scene (destroy all, it looks really cool). I press `ESC` and I see window of loading the scene. I press load again (I want to reload), but it doesn't work. I see my destroyed castle.
Astonishing video and features, of course!
Added 1:
There was small problem with starting up. Archive must be packed into "C:/Thermite/", else programme can't load GL library (Ogre.log
Added 2: It's just a small notice.
If I have changed the scene (destroy all, it looks really cool). I press `ESC` and I see window of loading the scene. I press load again (I want to reload), but it doesn't work. I see my destroyed castle.
-
PolyVox
- OGRE Contributor

- Posts: 1316
- Joined: Tue Nov 21, 2006 11:28 am
- Location: Groningen, The Netherlands
- x 18
Thanks! I'm glad you like itFive_stars wrote:WOW! (And it's not the name of game)
Astonishing video and features, of course!
Ok, I've fixed this and updated the download. Please try it again if you get a chance and thanks for pointing it out.Five_stars wrote:Added 1:
There was small problem with starting up. Archive must be packed into "C:/Thermite/", else programme can't load GL library (Ogre.log).
Yeah, I noticed that. I will fix it at some point but it's not too important.Five_stars wrote:Added 2: It's just a small notice.
If I have changed the scene (destroy all, it looks really cool). I press `ESC` and I see window of loading the scene. I press load again (I want to reload), but it doesn't work. I see my destroyed castle.
-
Praetorian
- Google Summer of Code Student

- Posts: 171
- Joined: Fri Aug 10, 2007 10:37 pm
- Location: WA - USA
- x 5
-
triton
- Greenskin
- Posts: 138
- Joined: Thu Mar 13, 2008 10:25 pm
- Location: Portugal
-
PolyVox
- OGRE Contributor

- Posts: 1316
- Joined: Tue Nov 21, 2006 11:28 am
- Location: Groningen, The Netherlands
- x 18
Thanks for the positive feedback guys!
At the moment there are *a lot* of triangles (something like 250,000) and they are all fed to both the graphics and the physics engine. But in practice the physics engine can probably use a much lower resolution mesh (and the graphics engine will benefit from this too when rendering objects in the distance).
I'm developing on a laptop with Intel Core 2 Duo CPU and an NVidia 8600M GS. I get about 50 FPS when flying around and 5-10 FPS when destroying scenery. How does that compare to what you get?
Praetorian wrote:Looks amazing, I wish i had a better computer....
Yes, it is a little slow at the moment. The main culprit is the physics - especially when modifying the environment because lots of structures get updated.triton wrote:The demo runs really slow here, but the video looks really nice.
At the moment there are *a lot* of triangles (something like 250,000) and they are all fed to both the graphics and the physics engine. But in practice the physics engine can probably use a much lower resolution mesh (and the graphics engine will benefit from this too when rendering objects in the distance).
I'm developing on a laptop with Intel Core 2 Duo CPU and an NVidia 8600M GS. I get about 50 FPS when flying around and 5-10 FPS when destroying scenery. How does that compare to what you get?
-
triton
- Greenskin
- Posts: 138
- Joined: Thu Mar 13, 2008 10:25 pm
- Location: Portugal
-
FrameFever
- Platinum Sponsor

- Posts: 414
- Joined: Fri Apr 27, 2007 10:05 am
-
mr.Zog
- Halfling
- Posts: 46
- Joined: Mon Apr 23, 2007 8:38 pm
- Location: Austria
-
Praetorian
- Google Summer of Code Student

- Posts: 171
- Joined: Fri Aug 10, 2007 10:37 pm
- Location: WA - USA
- x 5
Not sure if this helps but with my ancient computer (512mb of ram, 1.8ghz Pentium 4 and a 128mb Radeon9600 Pro) the castle itself is displayed pure white (I assume I'm lacking the necessary shader support (my card supports ps/vs2.0... is 3.0 needed?). I get about 10-20fps without destroying anything and the destruction did work (I can see it in the white silouette) it becomes a slideshow after that, before stabilizing a bit later and returning to the 10-15 range. As I said earlier I wish I had a nicer computer... from the video and screenshots though it looks amazing 
-
PolyVox
- OGRE Contributor

- Posts: 1316
- Joined: Tue Nov 21, 2006 11:28 am
- Location: Groningen, The Netherlands
- x 18
Thanks for the feedback!
FrameFever wrote:...and the camera control is really strange.
Agreed... actually I've got used to it but it could be improved a lot. Some kind of auto-level or something as it's easy to end up sideways.mr.Zog wrote:A minor issue is that the camera control could be updated.
I haven't really thought about it - I just set the shader model to 3.0 to give myself some flexibility. However, it's not just texture mapping, I'm actually using a texture atlas to apply many textures in the same material. This requires some fragment shader code but maybe not 3.0. I'll try and provide fallback materials for the next version anyway.Praetorian wrote:Not sure if this helps but with my ancient computer (512mb of ram, 1.8ghz Pentium 4 and a 128mb Radeon9600 Pro) the castle itself is displayed pure white (I assume I'm lacking the necessary shader support (my card supports ps/vs2.0... is 3.0 needed?). I get about 10-20fps without destroying anything and the destruction did work (I can see it in the white silouette) it becomes a slideshow after that, before stabilizing a bit later and returning to the 10-15 range. As I said earlier I wish I had a nicer computer... from the video and screenshots though it looks amazing
Ha, I hadn't thought of them like that! But they are from the OgreBullet samples actually - I hope it's ok to reuse them for this demo...milliams wrote:I love the medieval Weighted Companion Cubes
-
Peeling
- Gnoblar
- Posts: 5
- Joined: Fri May 02, 2008 3:52 pm
-
PolyVox
- OGRE Contributor

- Posts: 1316
- Joined: Tue Nov 21, 2006 11:28 am
- Location: Groningen, The Netherlands
- x 18
Cool! Actually I researched the Worms 'Poxel' Engine a year ago as I was going to write a paper about my approach and was looking for similar work. I came across someone called Andy (I think) but never got around to contacting him (I still haven't written the paper...). Is that you by any chance?Peeling wrote:Believe it or not I wrote the Worms3D and Worms Mayhem landscape engines; it's cool to see similar tech being worked on.
Well I'm glad you like it, the physics integration is cool but to be honest I'm amazed it works as well as it does. It *really* needs optimising.
So can you give me any tips from worms, or is it all under NDA? I'd be particularly interested in any tips on how you generated texture coordinates for the mesh - I'm currently using triplanar texturing but wondering if there is a better way...
Anyway, good to here from you!
-
Peeling
- Gnoblar
- Posts: 5
- Joined: Fri May 02, 2008 3:52 pm
Certainly isCool! Actually I researched the Worms 'Poxel' Engine a year ago as I was going to write a paper about my approach and was looking for similar work. I came across someone called Andy (I think) but never got around to contacting him (I still haven't written the paper...). Is that you by any chance?
I doubt anyone will mind if I pass on what I learned, so sure. I'll put together some info and post it ASAP.So can you give me any tips from worms, or is it all under NDA? I'd be particularly interested in any tips on how you generated texture coordinates for the mesh - I'm currently using triplanar texturing but wondering if there is a better way...
-
Peeling
- Gnoblar
- Posts: 5
- Joined: Fri May 02, 2008 3:52 pm
Ok, here goes 
The issue of texturing in W3D/M is really bound up with broader issues surrounding the poxel engine and the game as a whole. Before W3D, I'd always started with a tech concept and built the game around what that technology was capable of. With W3D, that wasn't an option. Worms already had a very distinct graphical style which needed to be reproduced in 3D.
We looked at the existing marching boxes demos, but although they were very impressive, they didn't actually LOOK any good. All the coders would stand around marvelling at the achievement, and all the artists would stand around saying "Hell, I can't make anything look good using that!" And at the end of the day, an engine only looks as good as the artists can make it look.
It was therefore very quickly apparent that a straightforward voxel lattice wasn't going to work. Plus the game had to run on a 32mb PS2, so setting aside 16mb or so for a voxel array of reasonable resolution was impossible. And as for texturing - well, having a 'material' for each voxel just doesn't cut it: an artist needs to be able to put a door texture on a door, a window texture on a window - they need real control.
Taking all this into account, I replaced the idea of a single voxel lattice with multiple ones, each of which could be positioned and oriented independently. At first, the idea was to have, say, one lattice for a house, another for a tree, with voxels within those lattices used to produce the detailed structure. To facilitate the organic worms style, I also added progressively more deformation options to the lattices: first a heightmap applied across the X/Y plane of the lattice, then two independent shear/taper deformations along the X/Z and Y/Z planes, and finally upgrading the shear/taper deformations to have seperate values for each layer within the lattice, which allowed the artists to create bent, organic shapes. Almost immediately, the 'one lattice per object' notion was tossed out: we ended up with landscapes consisting of 500+ individual lattices, some consisting of just a few highly deformed voxels. Drawing with voxels, you see, is horrible. The artists usually ended up just filling each lattice completely to the brim and then shaping it to fit, with the individual voxels only really coming into play as the landscape was destroyed
The texturing problem was overcome by dividing the generated geometry into top, bottom and side polygons, with a seperate custom texture projection onto each surface. The projection occurred after the heightmap was applied but before the edge-deformation tapering, so brickwork would follow the curved shapes of the walls.
Rather than one material per voxel, we allowed two, and had a per-corner blend value to permit smooth transitions. We also discarded the raw marching boxes algorithm in favour of a bespoke system which optionally crenellated the walls and rolled-off the edges of each lattice - each voxel was essentially divided into four and skinned with polygons accordingly. Finally we added details like grass edges.
As you can imagine, in all this the lovely simple collision detection you're enjoying went completely out of the window. We also had an even worse problem: we couldn't afford to drop frames on the PS2, but at the same time we couldn't regenerate the landscape fast enough if a huge explosion went off. We had to timeslice the regeneration - which meant that we couldn't use the landscape geometry for collision. During regeneration, it would be leaky. We had to use the raw voxel data. Fortunately, the poxel deformations I'd devised were reversible, so you could tell reasonably quickly whether a given point in space was inside a poxel. Surface normal calculation, on the other hand, was indescribably hideous.
Then there was the self-shadowing - again, not something we could just omit because it was hard
Each lattice chunk had a list of shadow dependencies - chunks that needed to be rechecked if that chunk was damaged. On top of that we ended up caching which voxel was occluding each vertex in the landscape, so that after an explosion we could very, very quickly check whether any given vertex was affected.
In W4 Mayhem, I added point light sources. They couldn't overlap, but they cast shadows and all the rest of it - a humongous ball-ache, frankly, but it looked nice. I also added a simple low-res heightmap under the whole scene to provide a cheap, area-filling base upon which landscapes could be constructed.
In short, to get a voxel engine that actually looked like a proper game and wouldn't give the artists an embolism, I had to prioritise the features they needed: control over texturing and shape. Everything else had to be engineered around that. I'm actually really proud of the result - second only to the worm animation system in W4
For that reason, I'd strongly advise you to think about what your engine is going to be used for - and by who - before piling too many features on top.
Anyway, hope that helps a bit.
The issue of texturing in W3D/M is really bound up with broader issues surrounding the poxel engine and the game as a whole. Before W3D, I'd always started with a tech concept and built the game around what that technology was capable of. With W3D, that wasn't an option. Worms already had a very distinct graphical style which needed to be reproduced in 3D.
We looked at the existing marching boxes demos, but although they were very impressive, they didn't actually LOOK any good. All the coders would stand around marvelling at the achievement, and all the artists would stand around saying "Hell, I can't make anything look good using that!" And at the end of the day, an engine only looks as good as the artists can make it look.
It was therefore very quickly apparent that a straightforward voxel lattice wasn't going to work. Plus the game had to run on a 32mb PS2, so setting aside 16mb or so for a voxel array of reasonable resolution was impossible. And as for texturing - well, having a 'material' for each voxel just doesn't cut it: an artist needs to be able to put a door texture on a door, a window texture on a window - they need real control.
Taking all this into account, I replaced the idea of a single voxel lattice with multiple ones, each of which could be positioned and oriented independently. At first, the idea was to have, say, one lattice for a house, another for a tree, with voxels within those lattices used to produce the detailed structure. To facilitate the organic worms style, I also added progressively more deformation options to the lattices: first a heightmap applied across the X/Y plane of the lattice, then two independent shear/taper deformations along the X/Z and Y/Z planes, and finally upgrading the shear/taper deformations to have seperate values for each layer within the lattice, which allowed the artists to create bent, organic shapes. Almost immediately, the 'one lattice per object' notion was tossed out: we ended up with landscapes consisting of 500+ individual lattices, some consisting of just a few highly deformed voxels. Drawing with voxels, you see, is horrible. The artists usually ended up just filling each lattice completely to the brim and then shaping it to fit, with the individual voxels only really coming into play as the landscape was destroyed
The texturing problem was overcome by dividing the generated geometry into top, bottom and side polygons, with a seperate custom texture projection onto each surface. The projection occurred after the heightmap was applied but before the edge-deformation tapering, so brickwork would follow the curved shapes of the walls.
Rather than one material per voxel, we allowed two, and had a per-corner blend value to permit smooth transitions. We also discarded the raw marching boxes algorithm in favour of a bespoke system which optionally crenellated the walls and rolled-off the edges of each lattice - each voxel was essentially divided into four and skinned with polygons accordingly. Finally we added details like grass edges.
As you can imagine, in all this the lovely simple collision detection you're enjoying went completely out of the window. We also had an even worse problem: we couldn't afford to drop frames on the PS2, but at the same time we couldn't regenerate the landscape fast enough if a huge explosion went off. We had to timeslice the regeneration - which meant that we couldn't use the landscape geometry for collision. During regeneration, it would be leaky. We had to use the raw voxel data. Fortunately, the poxel deformations I'd devised were reversible, so you could tell reasonably quickly whether a given point in space was inside a poxel. Surface normal calculation, on the other hand, was indescribably hideous.
Then there was the self-shadowing - again, not something we could just omit because it was hard
In W4 Mayhem, I added point light sources. They couldn't overlap, but they cast shadows and all the rest of it - a humongous ball-ache, frankly, but it looked nice. I also added a simple low-res heightmap under the whole scene to provide a cheap, area-filling base upon which landscapes could be constructed.
In short, to get a voxel engine that actually looked like a proper game and wouldn't give the artists an embolism, I had to prioritise the features they needed: control over texturing and shape. Everything else had to be engineered around that. I'm actually really proud of the result - second only to the worm animation system in W4
For that reason, I'd strongly advise you to think about what your engine is going to be used for - and by who - before piling too many features on top.
Anyway, hope that helps a bit.
-
PolyVox
- OGRE Contributor

- Posts: 1316
- Joined: Tue Nov 21, 2006 11:28 am
- Location: Groningen, The Netherlands
- x 18
Wow, that is a lot of useful advice! Thanks a lot 
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.
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?
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.
Thanks for the feedback!
That's one of the use cases I've been thinking about though I haven't put it in the tech demo. It has the advantage that you can save a lot of memory (because your not storing anything for empty regions of space), and also it integrates nicely with existing engines. For example you can have a regular non-destructible room built of polygons, and in the room you can have some destructible statues built of voxels. I was expecting to provide one transformation per volume and the detail of the statue would then be done by setting the values of individual voxels as you describe.Peeling wrote:Taking all this into account, I replaced the idea of a single voxel lattice with multiple ones, each of which could be positioned and oriented independently. At first, the idea was to have, say, one lattice for a house, another for a tree, with voxels within those lattices used to produce the detailed structure.
Peeling wrote:... I also added progressively more deformation options to the lattices ... and finally upgrading the shear/taper deformations to have seperate values for each layer within the lattice, which allowed the artists to create bent, organic shapes.
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.Peeling wrote:The artists usually ended up just filling each lattice completely to the brim and then shaping it to fit, with the individual voxels only really coming into play as the landscape was destroyed
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.
I've thought about storing multiples values per voxels and it can have several uses. Blending of materials (as you mention), perhaps also weighting so that the polygon surface can be controlled more carefully for sharp corners or smooth curves. You could also give a voxel a strength so that multiple hits are required to destroy it.Peeling wrote:The texturing problem was overcome by dividing the generated geometry into top, bottom and side polygons, with a seperate custom texture projection onto each surface. The projection occurred after the heightmap was applied but before the edge-deformation tapering, so brickwork would follow the curved shapes of the walls.
Rather than one material per voxel, we allowed two, and had a per-corner blend value to permit smooth transitions. We also discarded the raw marching boxes algorithm in favour of a bespoke system which optionally crenellated the walls and rolled-off the edges of each lattice - each voxel was essentially divided into four and skinned with polygons accordingly. Finally we added details like grass edges.
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?
Regenerating 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.Peeling wrote:As you can imagine, in all this the lovely simple collision detection you're enjoying went completely out of the window. We also had an even worse problem: we couldn't afford to drop frames on the PS2, but at the same time we couldn't regenerate the landscape fast enough if a huge explosion went off. We had to timeslice the regeneration - which meant that we couldn't use the landscape geometry for collision. During regeneration, it would be leaky. We had to use the raw voxel data. Fortunately, the poxel deformations I'd devised were reversible, so you could tell reasonably quickly whether a given point in space was inside a poxel. Surface normal calculation, on the other hand, was indescribably hideous.
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?Peeling wrote:Then there was the self-shadowing - again, not something we could just omit because it was hardEach lattice chunk had a list of shadow dependencies - chunks that needed to be rechecked if that chunk was damaged. On top of that we ended up caching which voxel was occluding each vertex in the landscape, so that after an explosion we could very, very quickly check whether any given vertex was affected.
In W4 Mayhem, I added point light sources. They couldn't overlap, but they cast shadows and all the rest of it - a humongous ball-ache, frankly, but it looked nice. I also added a simple low-res heightmap under the whole scene to provide a cheap, area-filling base upon which landscapes could be constructed.
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.
Well the truth is I'm just seeing what I can do with the technology - I don't have a particular game concept in mind. But I think the important point is that I really have to consider the artists if I expect anyone to make use of the engine.Peeling wrote:In short, to get a voxel engine that actually looked like a proper game and wouldn't give the artists an embolism, I had to prioritise the features they needed: control over texturing and shape. Everything else had to be engineered around that. I'm actually really proud of the result - second only to the worm animation system in W4
For that reason, I'd strongly advise you to think about what your engine is going to be used for - and by who - before piling too many features on top.
Thanks for the feedback!
-
PolyVox
- OGRE Contributor

- Posts: 1316
- Joined: Tue Nov 21, 2006 11:28 am
- Location: Groningen, The Netherlands
- x 18
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?


