TylerH

You list CryEngine3 as: Entity Based System - No Low End Support - No OpenGL Commands - No (This isn't even something you should be listing, since you already have an OpenGL Support) Cross Platform - No CryENgine 3 is entity based - Yes, Has low end fallbacks to DX9 - Yes, and is more Cross Platform than Leadwerks is - Yes. So with that, CryENgine 3 becomes 15 points, and is #1. Your chart is definitely biased, as it biases towards OpenGL, giving OGL based engines 2x more points if they are simply OpenGL, and it falls under YOUR opinion of what cross platform is. Running something under WINE isn't cross platform, it is emulation. Other engines on there, on the other hand, compile natively on non Windows/PC platforms.

Following in Niosop's footsteps, I borrowed his technique of blitting, if you want to call it that, the contents of an unsigned char buffer into a Leadwerks texture handle the contents of a video. I applied it to the Awesomium library, which is a wrapper of Google's Chromium Web Engine, built ontop of Java V8, Web Kit, and some nice HTML renderer, and it supports everything including Flash, HTML5, CSS3, etc. because of the dependence on Webkit. I integrated it into a small, kind of hackish, and horribly unoptimized demo that also handles mouse movement (in 3D) and mouse buttons, however, the mouse XY values skew at obligue angles. So, if anyone knows how to unproject and reproject 3D mouse coordinates to get them relative the camera rotation, that would make this work for all shapes at all angles. Picture is in the gallery. Here is the code: #include "engine.h" #include <gl/gl.h> #include "WebCore.h" static Awesomium::WebView* webView = 0; static TBuffer currentbuffer = 0; static TBuffer testbuffer = 0; static TTexture testtexture = 0; static bool drawPage = false; class MyWebViewListener : public Awesomium::WebViewListener { public: MyWebViewListener() { } void onBeginNavigation(const std::string& url, const std::wstring& frameName) { drawPage = false; //std::cout << "Navigating to URL: " << url << std::endl; } void onBeginLoading(const std::string& url, const std::wstring& frameName, int statusCode, const std::wstring& mimeType) { //std::cout << "Begining to load URL: " << url; //std::cout << "\n\twith status code: " << statusCode; //std::wcout << L"\n\twith mime-type: " << mimeType << std::endl; } void onFinishLoading() { drawPage = true; } void onCallback(const std::string& name, const Awesomium::JSArguments& args) { } void onReceiveTitle(const std::wstring& title, const std::wstring& frameName) { } void onChangeTooltip(const std::wstring& tooltip) { } #if defined(_WIN32) void onChangeCursor(const HCURSOR& cursor) { } #endif void onChangeKeyboardFocus(bool isFocused) { } void onChangeTargetURL(const std::string& url) { } }; int nextPow2(int x) { int y; for (y=1;y<x;y*=2); return y; } int main( int argn, char* argv[] ) { Initialize() ; RegisterAbstractPath("."); SetAppTitle( "Leadsomium" ) ; Graphics( 800, 600 ) ; AFilter() ; TFilter() ; TCamera camera; TFramework framework=CreateFramework(); TLayer layer = GetFrameworkLayer(0); camera=GetLayerCamera(layer); SetSSAO(0); SetBloom(0); SetHDR(0); SetAntialias(1); SetGodRays(0); PositionEntity(camera,Vec3(0,0,-3)); TMesh cube = CreateCube(0); PositionEntity(cube, Vec3(0, 0, 0)); ScaleEntity(cube, Vec3(2,2,2)); //RotateEntity(cube, Vec3(-90,0,0),1); //TurnEntity(cube, Vec3(0,90,0)); //PointEntity(cube,camera,1); //PointEntity(cube,camera,2); //PointEntity(cube,camera,3); testbuffer = CreateBuffer(1024,1024,BUFFER_COLOR); testtexture = CreateTexture(1024,1024,TEXTURE_RGBA); TMaterial testmaterial = LoadMaterial("abstract::web.mat"); TextureFilter(testtexture, TEXFILTER_PIXEL); SetMaterialTexture(testmaterial, testtexture); PaintEntity(cube, testmaterial); Awesomium::WebCore* webCore = new Awesomium::WebCore(Awesomium::LOG_VERBOSE, true, Awesomium::PF_RGBA); webView = webCore->createWebView(1024, 1024); webView->loadURL("http://www.leadwerks.com/werkspace"); MyWebViewListener* myListener = new MyWebViewListener(); webView->setListener(myListener); while( !KeyHit() && !AppTerminate() ) { if( !AppSuspended() ) // We are not in focus! { TurnEntity(cube, Vec3(0,0.025,0)); //if (isRunning) webCore->update(); if (drawPage) { unsigned char* buffer = new unsigned char[1024 * 1024 * 4]; webView->render(buffer, 1024 * 4, 4); currentbuffer = CurrentBuffer(); SetBuffer(testbuffer); BindTexture(testtexture); glTexImage2D(GL_TEXTURE_2D,0,GL_RGBA,1024,1024,0, GL_RGBA,GL_UNSIGNED_BYTE,buffer); SetBuffer(currentbuffer); delete buffer; } // Update timing and world UpdateFramework(); // Render RenderFramework(); TPick p; CameraPick(&p, camera, Vec3(MouseX(), MouseY(), 500)); float mx = 0; float my = 0; if (p.entity && p.entity == cube) { mx = p.X / EntityScale(p.entity).X; my = p.Y / EntityScale(p.entity).Y; mx = mx + 0.5; my = my + 0.5; my = 1.0 - my; mx = mx * 1024; my = my * 1024; webView->injectMouseMove(mx,my); if (MouseHit(1)) { webView->injectMouseDown(Awesomium::LEFT_MOUSE_BTN); } if (MouseHit(2)) { webView->injectMouseDown(Awesomium::RIGHT_MOUSE_BTN); } if (MouseHit(3)) { webView->injectMouseDown(Awesomium::MIDDLE_MOUSE_BTN); } if (!MouseHit(1)) { webView->injectMouseUp(Awesomium::LEFT_MOUSE_BTN); } if (!MouseDown(2)) { webView->injectMouseUp(Awesomium::RIGHT_MOUSE_BTN); } if (!MouseDown(3)) { webView->injectMouseUp(Awesomium::MIDDLE_MOUSE_BTN); } } DrawText(0,40, "LX: %f, LY: %f", mx, my); // Send to screen Flip(0) ; } } // Done return Terminate() ; }

I will take a crack at rewriting this in C++ for Leadwerks soonish. Working on finalizing this little embedded web player demo.

Ok, I tested loading it in passing TH_YUV to use the default YUV encoding, and convert it to RGB colorspace in the mesh.frag shader. I would like to note that I got 530 FPS using the TH_RGB with no conversion via shader code, and 500 or lower FPS using the conversion. When you think about it, the mesh.frag shader is going to run much slower because of how large the video resolution is, etc. So it becomes a factor that depends on a lot of variables. Using the shader-based approach really seems like overkill, when with only 1 worker thread LibTheoraPlayer seems to load right into RGB pretty darn fast.

I will work on modifying this for you to not use the SetBuffer commands, but it WILL introduce a few more direct OpenGL calls, but speed is the key here, not the comamnd count. @Rick: There is a set of OpenGL scripts for Lua that expose it. I believe Lumooja tested them out before and verified they worked, but I am not 100% sure.

Oh , sweet. My praise to Niosop

obj2phy is a direct conversion to a convex hull, so it should work fine...

It would be cool if we actually had some source code to look at...

If I can get around to it later today I will write a document explaining shaders in Leadwerks. I have wanted to do it for a long time both to help other people out with it, and to use as a reference while I take on rewriting the mesh shaders to be more robust (they are pretty unoptimized too).

This is from postfilter.frag: In this code fragcoord is a 0.0 to 1.0 texture coordinate that corresponds to the full screen quad that is drawn for the given effect. 0,0 is top left. 0,1 is bottom left; 1,0 is top right 1,1 is bottom right varying vec4 fragcolor; varying vec4 fragcoord; //========================================== //Textures //========================================== uniform sampler2D texture0; //color uniform sampler2D texture1; //depth uniform sampler2D texture2; //normal uniform sampler2D texture3; //blurred bloom buffer uniform sampler2D texture4; //unblurred bloom buffer uniform sampler2D texture5; //caustics frame 1 uniform sampler2D texture6; //blurred DOF texture uniform sampler2D texture7; //wobble texture / caustics frame 2 uniform sampler2D texture10; //noise texture for effects uniform sampler2D texture11; //ssao texture uniform float contrast = 1.0; uniform float brightness = 1.0; uniform float saturation = 1.0; //========================================== //Automatic uniforms //========================================== uniform float apptime; uniform vec2 buffersize; uniform vec2 camerarange; uniform float camerazoom; include "depthtozposition.frag"

Shadow Shader for convenience if we reference it in the thread again: varying vec2 texcoord0; uniform float apptime; uniform vec3 cameraposition; uniform float meshlayerrange; uniform float meshlayerheight; uniform float vegetationviewdistance; uniform float vegetationheight; void main(void) { vec4 modelvertex = gl_Vertex; Include "GetMatrix.vert" #ifdef LW_SKIN mat = GetAnimMatrix( int(boneindices[0]) ) * gl_Color[0]; mat += GetAnimMatrix( int(boneindices[1]) ) * gl_Color[1]; mat += GetAnimMatrix( int(boneindices[2]) ) * gl_Color[2]; mat += GetAnimMatrix( int(boneindices[3]) ) * gl_Color[3]; //mat = animmatrix[ int(boneindices[0]) ] * gl_Color[0]; //mat += animmatrix[ int(boneindices[1]) ] * gl_Color[1]; //mat += animmatrix[ int(boneindices[2]) ] * gl_Color[2]; //mat += animmatrix[ int(boneindices[3]) ] * gl_Color[3]; #endif #ifdef LW_MESHLAYER mat[3].y=0.0; #endif modelvertex = mat * modelvertex; #ifdef LW_MESHLAYER //Align to terrain height modelvertex.y += GetTerrainHeight(modelvertex.xz); float mld = length(modelvertex.xyz - cameraposition )/vegetationviewdistance; mld = clamp( (mld-0.75)*4.0, 0.0, 1.0 ); modelvertex.y -= mld * vegetationheight; #endif #ifdef LW_SWAY float seed = mod(apptime / 100.0 * 0.25,360.0); seed += mat[3].x*33.0 + mat[3].y*67.8 + mat[3].z*123.5; seed += gl_Vertex.x + gl_Vertex.y + gl_Vertex.z; vec4 movement = vec4( vec3( gl_Color.x * gl_Normal * LW_SWAY * (sin(seed)+0.25*cos(seed*5.2+3.2)) ),0.0); modelvertex += movement; #endif gl_Position = gl_ModelViewProjectionMatrix * modelvertex; texcoord0=gl_MultiTexCoord0.xy; #ifdef __GLSL_CG_DATA_TYPES gl_ClipVertex = gl_ModelViewMatrix * modelvertex; #endif }

In a fragment shader, a "varying" prefixed variable is a value interpolated per-pixel, which is assigned to in the vertex shader. So mesh_shadow.vert will define texcoord0. Typically one does: varying vec2 texcoord0; void main() { texcoord0 = gl_MultiTexCoord0.xy; }

Will this be written as a full screen shader, or a per-mesh shader? Most full-screen post processing effects follow this: texture0 = Color Buffer texture1= Depth Buffer texture2 = Normal Buffer texturen... = Bloom Blur Buffer, Caustics, etc.

The best way would be to write a game state system, typically called "screens". You have a Screen structure with an Update, Render, Finish set of member functions. A ScreenManager has a handle to the ActiveScreen, and will call the Update and Render functions for it. When Finish is called, next loop the screen manager will go to the next screen. We use such a system in Jeklynn Heights to go from Main Menu -> Loading Screen -> Game. And from game the next screen is GameScreen, when you press Escape.

You could skip creating a convex hull, and when you call LoadModel in your game or drag it into the editor, a much more detail .phy file is usually generated.

I always convert via Paint.NET to dds because it has the format drop down box, I can select the error metric, a checkbox to generate mipmaps, it has a preview window, and I can choose to weight the color by the alpha. It is a pretty great program.

The depth-buffer when drawn as an image on screen will appear as a 0.0-1.0 black to white buffer, that is either black at 0 (closest) and white at 1 (farthest), or inverted. Some render pathways will invert it because of the absoluteness you gain closer to 0, making 0 = farthest, as to avoid depth fighting issues between distant objects.

It will perform like a shadow map. If you think about it, a shadowmap tells the light shader where NOT to light. The "rain map" would tell the particle shader where to NOT show particles, by simply discarding those fragments. In an orthogonal camera projection, there is no perspective, and everything will be the same size no matter the distance.

As always you are correct. That setup seems great actually

The only way you could do that is if you rendered Terrain, followed by Weather Emitters, then render Models on top of that. A friend of mine and I coded a system for this in Garry's Mod to simulate rain: 1) Line Picks were used to test if you hit the sky box, if so, then a wobbly quad was drawn full screen with some DOF effects for rain. 2) If rain was on at all, emitters were drawn, but in the same world as the normal meshes so the buildings would draw overtop of the particles. 3) If inside a building and looking out, a test was done to convert the visible outside 3D portion to a 2D Screenspace, and the rain effect was only drawn over that area.

I understand. I wasn't suggesting using an infinite plane. I was just stating that it would be cool if we could apply the default water shader to a multiple number of planes/cubes/etc in the level to do things like lakes, ponds, puddles, etc.

Well, I really only need the IsGroup command, which isn't an entity at all, so no go there.

This is pretty cool, but I have to ask, why aren't you just using the default Leadwerks water shader applied to the plane? Then you can just render all your puddles like the single infinite water plane, and there you go... EDIT: I guess because the water shader doesn't seem to work when applied to other meshes, lol. Answered my own question.

IsEntity, IsPivot, IsMesh, IsModel IsGroup, IsEmitter, IsLight, etc. I require a command like that in C++ in order to properly rewrite LoadScene, since the group of subobjects in Blitzmax holds Object and you cast it to TGroup for groups, I need to be able to tell if the given byte pointer is a group, and call commands on it accordingly, as opposed to casting, which I obviously can't do.

Yeah, today a good physics ragdoll setup would simulate the IK better than a solver may.