BV Demo Game - Merry Christmas from GDGi
i get 30-60fps on a Atlon 2000+ geforcefx5500; but collision doesn't work properly: Look, i am inside a radar! Also there are walls i can go trough and some platforms i can jump through.
- Attachments
-
- BVDemo 2005-12-28 21-27-16-92.JPG
- (26.93 KiB) Downloaded 92 times
Everyone can see the difficult, but only the wise can see the simple.
-----
-----
collision
A couple of responses to the comments above:
1) Torque might cost $50 less for the base package, but this does not provide you with anything close to a working engine - you have to buy this add-on or that add-on and still don't get anywhere near the range of features that BV will provide out of the box.
re: collision
unlike RF & other similar engines, collision is not 'automatically' applied for geometry that you add to the environment. With Beyond Virtual you define a collision mesh for each object or model you load into the world. This allows you to optimize the collision as detailed as you want it to be (or not). By default, objects loaded into the world have no collision, it is up to the designer to specify what they want to be used for collision. You can render hundreds of thousands of poly's in a scene, but collision & physics is what will end up slowing down the engine eventually.
The buildings in particular are not the focus of the demo, and the collision is very stripped down on them, this is why you can go through some of the parts of the geometry. This isn't a 'bug' but a specific design decision that we made - the buildings are basically props for detail in the environment, we'll be doing more with them later on.
This is very similar to the renderware (ie gta etc) & larger-scale engines in how collision is handled. This is also why you can potentially fly/drive through areas in the level - the collision meshes were optimized and not every single poly has a collision volume for it.
For physics, you can specify that you want to use the rendered mesh for tri-mesh collision (ie terrain etc) or you can define seperate collision meshes for the model's collision (ie sphere, box, etc).
Any object in a scene can be handled by collision simply by giving it a mass and/or friction (among other properties).
The physics engine we're using at the moment is ODE, which is a less-than ideal physics engine - it has a lot of issues, to the point that we are going to strip it out at some point likely, potentially create our own. The physical properties in the world (gravity etc) are just set via the scripting, and yes they are not perfect by any means, but again this demo was created in about a month of part-time development, so with a larger/longer term project you could tweak the physics alot more. We didn't spend a whole long time on tweaking the physics really.
the demo was intended to demonstrate the fact that you can create a playable game in a short period of time. The demo was created by essentially 2 developers part-time (one artist, one scripter), with assistance from myself in a very part-time overseer role.
We'll be releasing a more 'tech' demo that shows the normal mapping, render-to-texture, depth of field etc (which are all supported) soon
The real 'next-gen' side of BV is the development environment, editing & art pipeline side - and once people start using it, you'll see a bit more of what we mean by this.
1) Torque might cost $50 less for the base package, but this does not provide you with anything close to a working engine - you have to buy this add-on or that add-on and still don't get anywhere near the range of features that BV will provide out of the box.
re: collision
unlike RF & other similar engines, collision is not 'automatically' applied for geometry that you add to the environment. With Beyond Virtual you define a collision mesh for each object or model you load into the world. This allows you to optimize the collision as detailed as you want it to be (or not). By default, objects loaded into the world have no collision, it is up to the designer to specify what they want to be used for collision. You can render hundreds of thousands of poly's in a scene, but collision & physics is what will end up slowing down the engine eventually.
The buildings in particular are not the focus of the demo, and the collision is very stripped down on them, this is why you can go through some of the parts of the geometry. This isn't a 'bug' but a specific design decision that we made - the buildings are basically props for detail in the environment, we'll be doing more with them later on.
This is very similar to the renderware (ie gta etc) & larger-scale engines in how collision is handled. This is also why you can potentially fly/drive through areas in the level - the collision meshes were optimized and not every single poly has a collision volume for it.
For physics, you can specify that you want to use the rendered mesh for tri-mesh collision (ie terrain etc) or you can define seperate collision meshes for the model's collision (ie sphere, box, etc).
Any object in a scene can be handled by collision simply by giving it a mass and/or friction (among other properties).
The physics engine we're using at the moment is ODE, which is a less-than ideal physics engine - it has a lot of issues, to the point that we are going to strip it out at some point likely, potentially create our own. The physical properties in the world (gravity etc) are just set via the scripting, and yes they are not perfect by any means, but again this demo was created in about a month of part-time development, so with a larger/longer term project you could tweak the physics alot more. We didn't spend a whole long time on tweaking the physics really.
the demo was intended to demonstrate the fact that you can create a playable game in a short period of time. The demo was created by essentially 2 developers part-time (one artist, one scripter), with assistance from myself in a very part-time overseer role.
We'll be releasing a more 'tech' demo that shows the normal mapping, render-to-texture, depth of field etc (which are all supported) soon
The real 'next-gen' side of BV is the development environment, editing & art pipeline side - and once people start using it, you'll see a bit more of what we mean by this.
((unlike RF & other similar engines, collision is not 'automatically' applied for geometry that you add to the environment. With Beyond Virtual you define a collision mesh for each object or model you load into the world. This allows you to optimize the collision as detailed as you want it to be (or not). By default, objects loaded into the world have no collision,))
Yes, that is the way 3dRad used meshes and collision. Newtonian physics for objects. but that was 3 years ago and the software has been dumped by the company for another project, I really like the BV interface, look foward to seeing what it really can do......
Yes, that is the way 3dRad used meshes and collision. Newtonian physics for objects. but that was 3 years ago and the software has been dumped by the company for another project, I really like the BV interface, look foward to seeing what it really can do......
how long did it take to create? including all resources used, of those made by your team? (noticed you used the counter-strike weapon pickup noise, not good)
got around to testing it on my desktop, and it ran great, though i would expect a demo like that would (athlon xp 2500+, radeon 9600pro). i can now see what they mean by the collision/physics issues
got around to testing it on my desktop, and it ran great, though i would expect a demo like that would (athlon xp 2500+, radeon 9600pro). i can now see what they mean by the collision/physics issues
- Attachments
-
- oops.JPG (8.33 KiB) Viewed 1157 times
RF2 site: http://realityfactory2.sourceforge.net/
RF2 tasks: http://sourceforge.net/pm/?group_id=179085
RF2 tasks: http://sourceforge.net/pm/?group_id=179085
Just to make it clear, I'm not saying that BV isn't good or hasn't the next-gen capabilities. I've said that the demo doesn't show them at all.
About the next-gen capability of rapid development, I'm sure of that, but you know that I can't see it in the demo
. So I'm encouraging you to make a different demo, not a rapid dev demo in two days. We can make it in RF, we can make all this, in the same way, using the testing physics release of RF (I don't want to exagerate but my hinge-car works much better than that ode car). We have seen some superb screenshot in the BV site and some nice movie. Why can't you release something like this, like an old school tech-demo and THEN show that all this is only a two-day work without troubles in BV? Look at the 3impact site: there are a series of fake tutorials just to show you that to use that engine is simple and plain like no other else. It's clearly false, there is a lot of work behind every demo and you can see the distinctive features of the engine in the same time.
I'm sure that if the good distinctiveness of this engine is rapid-prototyping plus next-gen stuff, you can show it togheter in the same demo. This will clearly persuade not all of us (we are yet conviced) but all the possible new BV users to pay for BV instead than for Torque (I didn't and don't want to pay for Torque!). I didn't want to be negative at all.
About the next-gen capability of rapid development, I'm sure of that, but you know that I can't see it in the demo
. So I'm encouraging you to make a different demo, not a rapid dev demo in two days. We can make it in RF, we can make all this, in the same way, using the testing physics release of RF (I don't want to exagerate but my hinge-car works much better than that ode car). We have seen some superb screenshot in the BV site and some nice movie. Why can't you release something like this, like an old school tech-demo and THEN show that all this is only a two-day work without troubles in BV? Look at the 3impact site: there are a series of fake tutorials just to show you that to use that engine is simple and plain like no other else. It's clearly false, there is a lot of work behind every demo and you can see the distinctive features of the engine in the same time. I'm sure that if the good distinctiveness of this engine is rapid-prototyping plus next-gen stuff, you can show it togheter in the same demo. This will clearly persuade not all of us (we are yet conviced) but all the possible new BV users to pay for BV instead than for Torque (I didn't and don't want to pay for Torque!). I didn't want to be negative at all.
I liked it. i was impressed by the speed improvement of the new version as well. 
My only gripes were the buggy physics and the lack of material effects. Both of which seem to be in the process of being resolved. The modelling was excellent. You have a good artist. The music was great. It seemed very stable as well. The only bugs i found were with physics (running into the canyon walls sent me flying about 400 feet in the air!)
Just one question though: What was with that gun? Compared to the world polycount it looked like something from Half-Life 1. No offense though, I know you guys were on a tight schedule. My weapons right now dont even have textures so your a step ahead of me. 
Great work and I look forward to the next demo and Indie Release.
My only gripes were the buggy physics and the lack of material effects. Both of which seem to be in the process of being resolved. The modelling was excellent. You have a good artist. The music was great. It seemed very stable as well. The only bugs i found were with physics (running into the canyon walls sent me flying about 400 feet in the air!)
Just one question though: What was with that gun? Compared to the world polycount it looked like something from Half-Life 1. No offense though, I know you guys were on a tight schedule. My weapons right now dont even have textures so your a step ahead of me.
Great work and I look forward to the next demo and Indie Release.
Check out my band
Tougher Than Fort Knox
Tougher Than Fort Knox
um
lack of material effects? what do you mean by this?
the effects for the ground (dust etc) for example is automatically generated on a per-material basis - this is all done automatically by the ground material, it isn't generated by the vehicle or player or weapons.
the entire demo was created in around a month, including adding alot of extra scripting commands, etc.
our initial goal with these demo's was to create a variety of game types using the engine to prove that we could actually do it - and whatever we ran into that wasn't possible via the scripting interface yet, was added.
the modeling & texturing of the content was done in perhaps 2 weeks, and the scripting side of the game (including packing it up etc) took perhaps another week.
btw, the sound effect is from a community-created sample pack for cs, it's not actually the default cs sound - close but not quite ;}
the models for the demo were created in a range of packages, including 3ds max, maya, lightwave and milkshape 3d - we did this on purpose to show that it is possible to do.
our next goal for demo's is a pure 'tech demo' that will be focused entirely on the 'flash' renderer features, etc - we'll probably use the same content as this demo, except we'll pack it with alot more toys.
looking back, i agree, we should have included more flash into the demo, but i really wanted to get something out before christmas - there will more than likely be updates to the demo as we go forward.
the effects for the ground (dust etc) for example is automatically generated on a per-material basis - this is all done automatically by the ground material, it isn't generated by the vehicle or player or weapons.
the entire demo was created in around a month, including adding alot of extra scripting commands, etc.
our initial goal with these demo's was to create a variety of game types using the engine to prove that we could actually do it - and whatever we ran into that wasn't possible via the scripting interface yet, was added.
the modeling & texturing of the content was done in perhaps 2 weeks, and the scripting side of the game (including packing it up etc) took perhaps another week.
btw, the sound effect is from a community-created sample pack for cs, it's not actually the default cs sound - close but not quite ;}
the models for the demo were created in a range of packages, including 3ds max, maya, lightwave and milkshape 3d - we did this on purpose to show that it is possible to do.
our next goal for demo's is a pure 'tech demo' that will be focused entirely on the 'flash' renderer features, etc - we'll probably use the same content as this demo, except we'll pack it with alot more toys.
looking back, i agree, we should have included more flash into the demo, but i really wanted to get something out before christmas - there will more than likely be updates to the demo as we go forward.
This is a pretty decent demo, good graphics, physics, guess you
could make everything collidable. Hard to tell if it's any good for
making games without some baddies, and seeing how hard it
is to script and make content.
The music in the racing game was
annoying. The car was slow, possibly because it had too many
polygons. The racing stunt game at walaber.com is a lot faster,
low-poly cars, etc.
could make everything collidable. Hard to tell if it's any good for
making games without some baddies, and seeing how hard it
is to script and make content.
The music in the racing game was
annoying. The car was slow, possibly because it had too many
polygons. The racing stunt game at walaber.com is a lot faster,
low-poly cars, etc.
You know, I played the demos and I saw great collision detection and the physics were cool!! Everything I hit bounced off just right and it happened in a believable way. Hmmm. I saw nothing wrong with it. Lot of fun.
I love the nitro burst. I crashed that buggy every which way you can!!! my boys are gonna love it!!
Mike, it is all excellent. Just keep your team moving in the direction you're going, and thanks for the terrific demo!!
I love the nitro burst.
I crashed that buggy every which way you can!!! my boys are gonna love it!!Mike, it is all excellent. Just keep your team moving in the direction you're going, and thanks for the terrific demo!!
Re: collision
Ok now i understand. The rest was cool. Blasting away those barrels with the gun made fun.gekido wrote: re: collision
unlike RF & other similar engines, collision is not 'automatically' applied for geometry that you add to the environment. With Beyond Virtual you define a collision mesh for each object or model you load into the world. This allows you to optimize the collision as detailed as you want it to be (or not). By default, objects loaded into the world have no collision, it is up to the designer to specify what they want to be used for collision. You can render hundreds of thousands of poly's in a scene, but collision & physics is what will end up slowing down the engine eventually.
The buildings in particular are not the focus of the demo, and the collision is very stripped down on them, this is why you can go through some of the parts of the geometry. This isn't a 'bug' but a specific design decision that we made - the buildings are basically props for detail in the environment, we'll be doing more with them later on.
This is very similar to the renderware (ie gta etc) & larger-scale engines in how collision is handled. This is also why you can potentially fly/drive through areas in the level - the collision meshes were optimized and not every single poly has a collision volume for it.
Everyone can see the difficult, but only the wise can see the simple.
-----
-----
-
Jim
yeah the demo was cool, im on old crappy hardware and once I got the updated demo it was very playable (first gen radeon anyone)
I would like to see a ramp near the gorge though, so I could jump it dukes of hazzard style, try as I may I kept plummeting to my death
I like the style of the demo, the orange sky was great and the models were great, with the excpetion of the gun I guess I'd have to agree on that point, but other then that cant wait for BV day!!
I would like to see a ramp near the gorge though, so I could jump it dukes of hazzard style, try as I may I kept plummeting to my death
I like the style of the demo, the orange sky was great and the models were great, with the excpetion of the gun I guess I'd have to agree on that point, but other then that cant wait for BV day!!
-
Guest
If that was true then, then it would be reflected in the assets of the game. (Which are all from TurboSquid anyways.) But I'm afraid that the quality of the demo and it's assets are way below par. Engines that have rapid development environemts are promoted with the assurance that it will allow artists to focus on assets. The majority of the assets in the demo are free and the rest look pretty shabby. (You could have at least made the terrain look good.)The real 'next-gen' side of BV is the development environment, editing & art pipeline side - and once people start using it, you'll see a bit more of what we mean by this.
Compared to RF, this doesn't seem to look better, run faster or be quicker to develop a game with.
All it seems to have above RF is ODE physics. (Or does RF have that now as well?) Speaking of ODE, what for? If it had it's own physics engine instead of having to interface with a third party product, it probably wouldn't have such buggy physics like it does.
-
Guest
This is PIckles. (might as well log in at this point)
So after playiog aorund with the demo for 15 minutes or so, here is my honest opinion...
I liked it. Didn't experience any of the bugs being mentioned. As a matter of fact, the physics ran so well, that it made it fun to just drive the car around. Much better then the Torque physics implementation by far. And yes, the shooting barrels was cool too.
Aside form the lack of effects which I won't mention since it wasn't part of the showcase, everything that was meant to be showcased ran great.
Tested on a Pentium 4 - 1.8 Ghz
512 Ram
ATI 9800
>>If that was true then, then it would be reflected in the assets of the game<<
C'mon, the sky was nice and the level geomtery looked good as well. Shadows would have helped though.
PS - Don't tell the GDG I said this. shhhh...
So after playiog aorund with the demo for 15 minutes or so, here is my honest opinion...
I liked it. Didn't experience any of the bugs being mentioned. As a matter of fact, the physics ran so well, that it made it fun to just drive the car around. Much better then the Torque physics implementation by far. And yes, the shooting barrels was cool too.
Aside form the lack of effects which I won't mention since it wasn't part of the showcase, everything that was meant to be showcased ran great.
Tested on a Pentium 4 - 1.8 Ghz
512 Ram
ATI 9800
>>If that was true then, then it would be reflected in the assets of the game<<
C'mon, the sky was nice and the level geomtery looked good as well. Shadows would have helped though.
PS - Don't tell the GDG I said this. shhhh...