Leadwerks Engine BlitzMax module (test 1)
BlitzMax Forums/BlitzMax Programming/Leadwerks Engine BlitzMax module (test 1)
| ||
| This includes the leadwerks.engine module and a few example programs: http://www.leadwerks.com/ccount/click.php?id=43 Example 1 demonstrates mesh instancing with a 2,000,000 polygon scene. You'll notice a significant difference in speed and polycount when you toggle frustum culling (F key). Example 2 demonstrates terrain construction from scratch. My engine uses terrain with tiling alpha-blended layers. The module could be used right now to write a terrain editor. Contact me if you want to do this. Example 3 demonstrates mesh creation from scratch, using an old Blitz3D .obj loader I ported to my engine. In addition to the old surface functions, you can also use analagous methods, like surface.AddVertex(x,y,z) or surface.VertexX(index). I have also introduced a new "World" convention. This will be used in the future for maintaining separate non-interacting worlds that can be rendered separately. For example, you might create a scene to be rendered in the background, and render this first before rendering the real scene. This is how backgrounds in HL2 work, and they are convenient because you can build one background in the editor, and use it for many scenes. Entities use the familiar Blitz3D functions, but now you can retrieve their local values a new way: x#=EntityX(myentity) x#=myentity.position.x x#=EntityPitch(myentity) x#=myentity.rotation.x You can also use these: x#=myentity.scale.x x#=myentity.quaternion.x I implemented quaterion rotation, which will give much better results with transformations, parenting, and especially animation. There is no reason you cannot write your own animation system with the current command set. I have some old HL2 model loader code somewhere, and I might just try it out. The ATI rendering speed problems should be resolved. I actually went to the lengths of programming the engine to behave differently based on the card vendor, since the setting that made rendering fast on NVidia cards was the opposite of what makes rendering fast on ATI cards, under those particular conditions. Very strange, but true. If you choose to modify a mesh on-the-fly, it will be much faster to do this: surf.lock() surf.vertexposition v,34.0,6.5,89.0 'make your changes surf.unlock() This is because surfaces get stored directly in gfx card memory, and locking the surface will prevent the engine from uploading the new data to the gfx card until you are done. Note that unlocking the surface will re-upload the entire surface to the gfx card, so don't use this unless you are altering lots of vertices. At this point I wanted to just deal with graphics. After I make sure everything is working, I will add Newton physics back in, which is what raycasting, collision, and even some lighting features are based on. Then I will proceed with shaders. I have most of this written already, but there are a few compatibility issues I want to resolve. As you can see, the engine can handle scenes up to about 4,000,000 polys on the newest hardware. I have tried dozens of rendering techniques and combinations over the last year and a half, and have discovered the fastest methods possible. |
| ||
| All the examples crash on my machine. Executing Example10 in Debug mode shows the error message "Unable to calculate tex size" at line 25 (mesh:TMesh=LoadMesh("watertank.mesh")). |
| ||
| That's why this is a test. :) Do the other examples give any error? |
| ||
| do i need to have MaxGUI to run this then? Cheers Charlie |
| ||
| I accidentally imported MaxGUI in the module. I have re-uploaded a new version that does not import MaxGUI. Same link. |
| ||
| Love the B3D style simplicity, love the power, love the possibilities. Runs nice and fast with no glitches here on my Nv 6600 |
| ||
| All i get when trying to compile example 1 is "Compile Error, could not find interface for brl.win32maxgui" Cheers Charlie |
| ||
| Ok, i'm getting an 'unable to calculate tex size' here as well. I've got an Intel GMA chip in my laptop, so that might be the problem. Cheers Charlie |
| ||
| Runs fine here, kudos. Also runs nice on my wife's comp (P4 2.4Ghz&Ati9500). |
| ||
| I can't imagine why you would be getting that error in GLAdjustTexSize(), unless your modules aren't synced. Try running this and see what it outputs: Framework leadwerks.engine
SetGraphicsDriver GLGraphicsDriver()
Graphics 800,600,0,60,2
pixmap:TPixmap=LoadPixmap("watertank.png")
Print "Pixmap: "+pixmap.width+" x "+pixmap.height
tex:TTexture=LoadTexture(pixmap)
Print "Texture: "+tex.width+" x "+tex.height |
| ||
| Building untitled1 Compiling:untitled1.bmx flat assembler version 1.66 3 passes, 1378 bytes. Linking:untitled1.exe Executing:untitled1.exe Pixmap: 0 x 2 Texture: 4513344 x 0 Process complete that seems to work fine. the window just flashed on and off the screen right? |
| ||
| It's not loading the pixmap correctly. Notice the dimensions are (0 x 2). You may need to sync mods. BRL.pngloader should be v1.04 or later. |
| ||
| Nothing to do with syncmods I think, minib3d has the same issue with Intel inegrated graphics, couple of GL calls not working, see the thread about release of v.41 in minib3d forum. It is not working on my Intel GMA laptop either and I have all mods sync'ed. |
| ||
| This has nothing to do with the graphics card. The pixmap .png loader is not working. I am familiar with the Intel integrated graphics chipset and its OpenGL oddities, but those are not related to this issue. Usually problems with the intel integrated chipset are due to using the projection matrix inappropriately: http://www.sjbaker.org/steve/omniv/projection_abuse.html jkrankie, please tell me what version of BRL.pngloader you have. |
| ||
| All examples compile and run fine here (whereas the earlier, building test had no textures on my ATI card). It looks good, and I'll be following your progress with interest. |
| ||
| Windows only eh? |
| ||
| @Leadwerks- What's the licencing for the engine if you release a game made with it commercially? |
| ||
| Excellent performance, but I'd like to see some collision-related stuff before I purchase a license. Also, a built-in .b3d loader would be essential and some command documentation. Overall, I’d have to say this is the most promising commercial 3d module for BlitzMax so far… BTW: Is there a TerrainY command in this test release or does that require Newton physics? |
| ||
| I'm not really selling anything for BlitzMax at this point, just making sure it works. Here are some terrain methods: Terrain.modify(grid_x,grid_y,height#) Terrain.height#(grid_x,grid_y) I also have an interpolated height method, but it has been disabled. This gives an estimate of the terrain height at some point between the vertices. It's useful for placing grass and things. There's also a lightmap field you can add a lightmap texture with: terrain.lightmap=LoadTexture("lightmap.bmp") |
| ||
| Cool. Works without problems on my ATI Radeon X800 GT... |
| ||
| dp |
| ||
| The last test ran ok, but this one want a GL vertex buffer? |
| ||
| You must have a really really old graphics card if it doesn't support the vertex buffer object extension. I could go without it, but if your graphics card is that old it probably only supports 2 texture units, and terrain requires at least 3 texture units to render correctly. |
| ||
| Works great on Nvidia 7600GT, and 7600GS. |
| ||
| Its a sis internal, so its not that is old, just rubish. The main point was that the last demo you asked ppl to look at, it worked, even to the point were I had the textures visable and others didnt. It seem strange now that it wont work at all. I had a similar argument with the XNA people, just because the end result needs something, (Some shader or other), shouldnt nessesaraly preclude development on a system that doesnt have that whatever. In XNA there was a hack that removed the thing, and the microsoft ppl condemed it, But Microsft workers are probably on a one year upgrade cycle, wereas Im on a three year upgrade (if Im lucky), at the end of which I buy cheap, and not good. So.... if its at all posible to remove some highend option, I would recomend letting ppl have the possibility of removing it, even if the result is "Unplesent". And this opinion continues down to some "Lowend" option etc.. |
| ||
| Until now, I did each terrain layer like this: texunit 0: lightmap+alphamap combined texunit 1: texture Many of my artists complain they want to be able to use an arbitrary-sized alpha map with terrain, so I did this to allow an alphamap at a resolution independent of the lightmap: texunit 0: lightmap texunit 1: texture texunit 2: alpha map This requires 3 texture units, so the GEForce 3 & 4 are out. I am planning to present my editor and engine at the GDC next year, so I don't think I will get anywhere by trying to support low-end or really old stuff. When it's possible, I go as far backwards compatible as I can, but I don't want to do so at the expense of the technology. I'm already offering a lot of backwards compatibility by even allowing a non-shader pipeline. Also, if you don't have support for the VBO extension, you can't really do instanced mesh batches at all. You might as well use Blitz3D if those are your target specs. |
| ||
| You might as well use Blitz3D if those are your target specs Thats practicaly exactly what the XNA ppl said.They are not my target spec. This is my laptop, my target specs is my desktop, the problem is most of my (experimental) development time is on this one. As the other one is normaly tiedup by the kids playing games (At the moment they are in a B&W 2 phase), so if at all posible, I like me dev tools to forgo the higher end stuff when in dev mode. I understand totaly if thats not possible, but you know...... |
| ||
| Well, Leadwerks, your terrain system is very good. I'm seeing excellent performance on my system and the layering facility is very useful. Any tips for creating skyboxes in code? I'm used to the blitz3d method (as per Mark’s Castle example – using brushes, etc). |
| ||
| Josh, your examples run fine on my old Sony VAIO VGN-A215M (Pentium M (1.6GHz), 512 MB, ATI Mobility Radeon 9200) Even Example 1 runs smoothly until I press "F" ;-) Very impressive! |
| ||
| Cant wait to see more |
| ||
| Very impressive and very easy-programming style! Good start! All the examples run perfectly! Athlon64 3500+ 2.2 Ghz, 1 Gb Ram, GeForce 6600gt |
| ||
| Hm , my intel Gma 915 returns 'unable to calculate tex size' (all 3 examples) as well. For me it can't be a coincidence as Jrankie has the same message, and as minib3d have the same issue but if you think different (png loader is up to date, v1.04)... will try your snippet this night. And it works fine and fast on my Nvidia 7800 Go! :) |
| ||
| All the examples give the 'Unable to calculate tex size' error, even the last one you posted, Josh. I also have an Intel GMA gfx card. |
| ||
| I have version 1.04 of the png loader. Cheers Charlie |
| ||
| Me too |
| ||
| Failed on a Fujitsu notebook 1510D (XPSP2) with a Intel® Graphics Media Accelerator 900. Worked on an XP desktop with nVidia 7600GS Worked on Vista Desktop with an nVidia 8800 GTS 320MB |
| ||
| Looking impressive so far. Had a sneaky look at work on an amd 64 3200+ with ati radeon 9550. Was about 20fps avr. on the first example, pretty damn good considering the card is naff. |
| ||
| Fujitsu 1510D is a tablet PC? If so you must disable advanced text options, but I suppose you know that. |
| ||
| Well with the above snippet it reports Pixmap: 128 x 128, but first it crashes on Loadtexture with Unable to calculate tex size. |
| ||
| Works great on my laptop. Acer intel Core Duo 1.66 ghz. 1gb ram, ATI mobility Radeon x1400 |
| ||
| Works fine on my Notebook too: Fujitsu Siemens Intel Duo Core 1995 MHz, Win XP Home, ATI Mobility Radeon 1300, 2 GB RAM |
| ||
| I got Newton raycasting to work on all geometry in a pretty flexible manner. It compiles a BSP for each mesh, as well as one large BSP for all BSPBrush geometry. You can move meshes around in the scene without having to recompile their bsp. However, BSP Brush geometry has to be recompiled each time it changes, and this can take a few seconds. Therefore I do not recommend moving BSPBrushes around in your scene. They should be considered static geometry. For dynamic or vertex-animated/skinned meshes I do not recommend performing raycasting, since this would require a recompile of the mesh BSP every time the vertices move. This is probably why animated characters in commercial games usually don't occlude light halos on a per-triangle basis, if at all. Newton's raycasting algorithm is much, much faster than anything else I have seen. It can perform 100 high-range raycasts in a high-poly scene in less than 1 msec. Considering the performance it provides, I think the constraints I have listed are acceptable. |
| ||
| Demos working fine here (Nvidia 8800). Nice going on the Newton side :) |
| ||
| Maybe a silly question but -- I'd like to test it but do I need BlitzMax or is it possible to test an executable? (I dont have BlitzMax) |
| ||
| Just download it and you will see that there are executables in... |
| ||
| Man, RESPECT to YOU!!! Examples is good) |
| ||
| I am using a volumetric technique for dynamic lights. Here's a 2 million-poly scene with 6 dynamic lights: http://www.leadwerks.com/post/vlights.zip I have got Newton back in. Working with Julio to resolve a few issues with scaling. Raycasting works, and it is crazy-fast. The module will be ready in about a week, maybe a little longer. |
| ||
| This has to be my next purchase...well done. |
| ||
| wow works fine mongia2 win xp nvidia 5700 ram 512 |
   |