More engine info
Blitz3D Forums/Blitz3D Programming/More engine info
| ||
| Projectors Projectors are the dynamic shadows you see in the Unreal Engine 2. When you walk under a light and you gun is illuminated with a fine shadow, or if you enter a room cast in the shadow of a spinning fan, or walk under a shaded tree, that is a projector. Projectors now work on brushes, staticmeshes, terrain, as well as moving objects like players and vehicles. Staticmeshes Staticmeshes are collapsed into batches on a per-portalzone basis. Fast line picking is possible with the optimized collision system. Colliding staticmeshes are stored as non-merged instances of the mesh. When a pick command is called, the engine first checks to see if the brush walls occlude the line of sight. If the point is still visible, the engine then runs through and checks each staticmesh. First, the engine checks the staticmesh's bounding box. If the bounding box of the mesh occludes the line of sight, the engine then does a check on the actual mesh triangles. With this technique, you very rarely even get to the level of checking mesh triangles, and if you do, it is unlikely that you will need to check more than one or two meshes. The unoptimized line of sight check would have to check each triangle in the scene. The optimized version eliminates perhaps 95% of the triangles. Coronas The optimized picking technique described above makes it possible to have large numbers of coronas, even in dense areas with lots of meshes. Additionally, coronas are rendered as a single surface, so you can pretty much have as many as you want. Portalzones Portalzones store chunks of the map. Visibility is automatically calculated by creating a list of adjacent or "touching" portalzones. If the camera resides in one portalzone, that portalzone and all adjacent portalzones are shown. Depending on the "iterations" value, all adjacent portalzones to those portalzones will be shown as well, for as many iterations as is indicated for that portalzone. The default value is "2", which means you can set up your zones, and usually won't have to indicate any iterations value, unless you are doing major optimization. Portalzone hiding and showing is used to efficiently deacticate graphical entities like coronas and emitters. It provides an efficient way of culling players and other moving objects. It also provides ridiculously optimized picking routines. For example, if point A is in one portalzone and point B is in another non-visible portalzone, we can return False without even checking visibility between the two. |
| ||
| gis the engine |
| ||
| Cool ... |
| ||
| Halo, You are not introducing where you are talking about...Are you talking about an engine you found on the Internet, or about an engine you'd like to make, or an engine you have made? Sorry, but you tend to forget an introduction that is neccassary to place your text in the right context... Your post now looks like a dictionairy. |
| ||
| the engine he's making. he made a big post about it a while ago. Still hard at work. I'm working on mine as well. Halo, how long have u been working on your engine? |
| ||
| I am almost done programming our engine and game(!). Staticmeshes can have pre-calculated lightmaps, as well as vertex lighting to fit the ambient environment. Portals you lay out (brushes) arbitrarily slice the map up into portalzones, which are automatically hidden and shown:  Terrains are split into BSP sectors. Antiportals are large brushes that occlude your view of portalzones hidden behind it, and they can be placed anywhere without any special settings. Detailed statistical information lets you see where slowdown occurs, and helps you optimize scenes:  Projectors cast shadows onto walls, meshes, players, weapons, vehicles, and even particles.  Add a texture shader, and shadows can rotate or scroll:  Optimized collision allows for fast visibility tests in areas of high mesh density:  |
| ||
| cool beans! The projectors screenie looks like a nuke just detonated, hard to see the shadowing. |
| ||
| That shot is full-bright, with the contrast cranked up. It is hard to see the moving tree shadows in a static screenshot. |
| ||
| Looks very nice, halo. |
| ||
| Wow! Looks like you're gonna get pay-back for all your hard work. That is looking like one slick system you got there. Question: Are you slicing your map mesh into zones with a Blitz routine or are you doing it with Max's slice tool? ..Also can you have real-time lighting with your shadow maps? Will a gun-flash or torch show on mapped shadows? |
| ||
| Dynamic lights are done with "decal lighting"; a circular gradient texture is mapped onto the walls and terrain. Thanks to the portal system, I can calculate these lights fast enough to use in real-time. Hardware lights are used on actors and other moving objects. Actors have dynamic projectors attached to them that cast the player shadow onto terrain and brushes, and work on lightmapped surfaces as well. |
| ||
| Halo - can you get a torch effect with decals?? I'm interested to know...I'm going through terrible angst with my stuff here trying to decide which way to do the lighting...if there was a way to do a torch effect on shadow mapped meshes that would be a cool answer. so far I can only get decent torch with hardware lights on a non-shadow mapped mesh which looks okay but the loss of shadows is a real tough lump of crap for me to swallow. |
| ||
| Yeah, that is the kind of thing that decal lights are good for. Your shadows will still be there, but you aren't going to have dynamic shadows cast by the torch. |
| ||
| Will you be selling the engine? I'm always on the lookout for new stuff ;) |
| ||
| Halo - sorry to go on about this but it has been causing me sleepless nights just recently as I can't make any real progress until I've nailed my lighting method down. I've experimented with every last method that I can think of and they've all produced a sort of lame half-light in areas of darkness that isn't really convincing at all. Unless I'm missing something, a decal light will only make a black area of shadowmap a lighter shade of grey won't it? It will not brighten up the underlying texture at all? (I'm sure I read somewhere that Blitz will do realtime lighting if the level map is an imported BSP map - this apparently can be shadow mapped and will still allow some sort of dynamic lighting. It's something I think I'll have to investigate properly.) |
| ||
| "For example, if point A is in one portalzone and point B is in another non-visible portalzone, we can return False without even checking visibility between the two." So blasting away in the direction of the enemy spawn across the map in the hope of getting a random headshot won't work? Damn. There goes my "skill" ;) +BlackD |
| ||
| gis' the engine |
| ||
| Slenkar, please stop posting gibberish. Hujiklo, you are right, you have to sandwich the light decal on top of the lightmap layer, and under the texture layer. So your lightmap texture layer would be 0. Then you use additive blending to add the dynamic light decal, layer 1. Then add your texture layer on top of that, at layer 2. Your lightmap should NOT use modulate2x blending. Instead, your texture should use modulate2x blending. This also has the benefit of keeping your vertex-lit and lightmapped objects looking uniform. Skitchy, the source for this will not be available, except maybe to someone who contacts me privately and is willing to pay a lot. (Well, not a lot considering everything it does, but more than a "cheap" gamedeve system.) I am leaning towards a modifiable engine, accessible via script, but something like that would probably be aimed more at the TGC community. You will never see a "cheap easy-to-use Blitz engine source", because it would frankly be unprofitable. |
| ||
| I am leaning towards a modifiable engine, accessible via script, but something like that would probably be aimed more at the TGC community. Do you finally use BlitzVirtualMachine for the scripting? If so, according to its license terms, you cannot use BVM for something which would be a "replacement" for Blitz. I think that a 3d gamedev system is a replacement for Blitz.Really nice screenshots here Josh, can't wait to play the game! |
| ||
| Thanks for the info Halo. Looks like I've still got some experimentation ahead of me. I just loaded up a quake3 bsp map and a spot light does indeed work perfectly in conjunction with the shadowed areas... though it obviously still requires decent tesselation for a smooth effect. I'll have to try and see if I can control the level of tesselation in anyway with a bsp map editor perhaps using smaller evenly spaced brushes...I'll see. |
| ||
| Jedive, with the work I have put into this, it really bears no resemblance to Blitz. I have bypassed most of the Blitz routines, because they were too slow or incomplete. I already talked to the author of BVM, and he has no problem. I would also clear it with Blitz Research. I don't expect a problem, because I have eliminated 95% of the Blitz commands. The script programmer would use commands like LoadMap(), JoinServer(), SpawnPlayer(), etc., and then the basic math commands that every language has. You wouldn't even be able to access mesh data or load file formats other than the special engine formats, so there is no chance of anyone replacing Blitz3D with this. It's more like programming in QuakeC. |
| ||
| Looks pretty tight halo. |
| ||
| 'gis' means 'give me the' you may as well tell us how much you are going to charge |
| ||
| Awesome work there Halo! Some of the best I have seen in B3D. |
| ||
| you may as well tell us how much you are going to charge I have no idea. I don't even know what kind of format it would come in. |
| ||
| Are you slicing your zones up in code or pre-code? |
| ||
| Post-code. |
| ||
| Halo, I hate to alarm you; but you are very...umm 'Unknown' at the moment o_O |
| ||
| perhaps banned for illegal planings as BVM is only allowed to Blitz owners if I'm not totally wrong ( which might theoretically be ) |
| ||
| BVM is only allowed to Blitz owners if I'm not totally wrong I'd like to make some precisions here. BVM is a script engine, and as such you have of course full right to make an application (being a game or not) that exposes its functionalities throught BVM scripts. The end users of this application don't need to own blitz, for you to use BVM.The obvious problematic situation is if someone tries to use BVM to create a "blank" program that simply executes blitz scripts, exposing the whole blitz command set - in such a way that it could theorically be used as replacement for blitz. *This* is explicitely forbidden by my license, and there is no discussion. Now, the license actually goes a bit further and states that you can't create a stand alone game engine with BVM, *unless BlitzResearch itself agrees with your use of BVM (though I might rephrase how I put it in the license to be clearer). In short, the extreme case is forbidden without discussion, and for the cases that *might* be problematic, I let BlitzResearch be the judge as they're the ones who could have direct problems with it (I don't). Any other use - like letting end users make MODs of a your game, which is the main purpose of BVM - simply can't pose the slightest problem. Now, about Halo's project, my feeling - given what he told me - was that it *should* really be OK for BlitzResearch. But as said, in this fuzzy area it's up to them. I doubt this is the reason for the ban. Halo has proved to have some blatant lack of skills in the "human relashionships" area, so there could be dozens of reasons... |
| ||
| So what's the real status on this engine? Is there any plan for a video demo or a full playable demo to showcase the engine's features in action? Even if this was a big-budget engine being done in C++ I'd still have to say 'wow' to those screenshots. I can't wait to see what it can do realtime! |
| ||
| The status of this engine is, I am working my ass off to finish it. I am working on CShop 5 at the same time, because I can't develop one without the other. The occlusion system is done, and it is really nice because you can deactivate particles and other entity updates that are out of view. Still to do: -Finish lighting system -Character shadows (dynamic animated projectors) -BSP terrain for faster collision and shadows |
| ||
| Halo, some thoughts: Once your engine is finished I think you're going to make a killing; it looks and sounds to me as if it's the most advanced of it's type, and will be for a long time. But another thought: Blitz programmers (the ones who don't buy your engine) are still going to want to code their own (just coz that's what they like to do) - in the longterm I think you should consider running seminars to explain the methodologies in the topics above. It could be a nice little earner! |
| ||
| I'm thinking this could end up being the Half-Life engine of the Blitz community. Everyone has access to a free SDK with source but not the actual engine source. The graphics are good enough to last a long while for hobbiests, and it gives you the freedom to modify gameplay to the point where it's almost an entirely new game (in other words, a Blitz mod engine). CShop better be free for owners of CShop 4 :D |
| ||
| Uber: Your joking - this is halo we are talking about! |
| ||
| Uber: Your joking - this is halo we are talking about! I've been working on this for three years, and it started to get real serious in the last six months. I have a safe deposit at the bank where I store backups, in case of a fire or water damage. No, I am not posting the source for free. The code might be available for licensing, but it would be for a significant price, definitely no less than $1,000 plus some percentage royalties, and I have seen no indication that any Blitz programmers want to invest that much money and time into a project. So I don't expect to license the source at all. |
| ||
| I never suggesting releasing the source. I was suggesting making the scripting system open for users to meddle with so they can make their own levels/mods for the engine. The whole source code? Honestly, I'm not that dense. |
   |