Josh

What's wrong with local networking? That's how I would do it. I think some OSs won't even let you use shared memory hacks. You can also use the command line and console output, if it is a start/stop kind of operation.

SetBlend().

One surface using one texture is faster than four surfaces using four textures. However, I don't think there is any significant difference, and you should use whatever makes things easier for you. I can't imagine it would be easy trying to make a big image containing all your different textures.

Inno setup is good and highly customizable.

Directional lights usually have to be recalculated every single frame, because the camera is usually in motion. One technique I want to try with directional lights is one of those skewing techniques. They are glitchier than cascaded shadow maps, but if something with reasonable results can be implemented, it will only require one render of the scene, instead of the three that CSM requires.

In Leadwerks Engine 2.3, two rendering paths are used for point lights. One uses a depth cubemap (for shader model 4 hardware). The SM3 fallback uses an unwrapped cubemap on a flat texture. On SM4 hardware, a depth cubemap was used because it allowed a point light to be rendered in one pass. However, when implementing my double-buffered technique for point lights, some problems arose. As a result, I changed the renderer to draw point lights as a series of six pyramidal volumes. This is how S.T.A.L.K.E.R. drew point lights, at least in Clear Sky. There was also a problem with NVidia cards not being able to read from a color cubemap unless it had mipmaps. Think for a moment about that, and you can probably guess where I am going with this... Now SM3 and 4 cards will use the same render routine for rendering point lights. SM3 hardware may be a bit faster, because the unwrapped flat cubemap texture coordinates took a lot of logic to figure out, but I don't think it will make any significant difference either way. I talked earlier about separating geometry into "static" and "dynamic" objects, and how the engine gained massive savings by only redrawing dynamic objects, unless otherwise needed. I took the concept a bit further, and decided to allow a light to cast shadows from static or dynamic geometry, or both. Consider the image below. The fan is in motion, but only about 1000 shadow polys have to be drawn to update the shadow: The large spot light projected through the fan blades is the dominant light, but the point light above the fan also casts shadows. If you look carefully, you may notice the oildrum in the foreground is not casting a shadow from the point light. The point light is set to only cast shadows from static geometry, so it never has to be redrawn (unless you move a static object in the editor). Because there are more dominant lights in the area, the viewer probably won't notice this technical error. This allows you place extra point or spot lights throughout a scene to create more detailed static lighting. The shadows will never be redrawn, and you can use them together with fully dynamic lights to create more lighting detail, without the cost of rendering more shadows.

or... require("scripts/class") local class=CreateClass(...) function class:CreateObject(model) local object=self.super:CreateObject(model) object.model:SetCollisionType(COLLISION_PROP) end

There is no official support for Python. However, I think some people have used Python with our engine. I recommend you look into Lua, as it is easy to use and effective.

This is a forum for discussing Leadwerks Engine.

Use Curve(), and have a lower threshold for the minimum distance the step can be.

Normally you think of baked lighting as, you have a long processing step that is done before the game runs, then you display the results and it is fast. You think of dynamic lighting as, okay, it will be slow because it has to update each frame, but it looks good. It's interesting that our approach has turned into, "display the results each frame, and only update it when it is absolutely necessary".

You can create a 2-triangle mesh (a quad) and use an alpha-masked material. The "sprite" will even cast shadows on the ground. Alternatively, you can simply draw the image on the screen with DrawImage().

Here's a version of driver.lua that makes the camera stay behind the vehicle and follow its rotation: require("Scripts/constants/keycodes") require("Scripts/linkedlist") require("Scripts/filesystem") require("scripts/math/math") require("scripts/constants/engine_const") FlushKeys() HideMouse() local camera = fw.main.camera chassis=LoadModel("abstract::vehicle_viperscout.gmf") carobject=objecttable[chassis] car=carobject.vehicle if car==nil then Notify("Vehicle object not found.",1) chassis:Free() return end chassis:SetPosition(TFormPoint(Vec3(0,-1,10),fw.main.camera,nil)) chassis:SetRotationf(0,camera.rotation.y+180.0,0) --Variables local dx=0.0 local dy=0.0 local camerapitch=camera.rotation.x local camerayaw=camera.rotation.y local move=0.0 local strafe=0.0 local steering = 0.0 local torque = 0.0 local steerlimit = 30.0 local steerrate = 2.0 local steerangle=0.0 MoveMouse(Round(GraphicsWidth()/2),Round(GraphicsHeight()/2)) while KeyHit(KEY_ESCAPE)==0 do --Camera look --[[ gx=Round(GraphicsWidth()/2) gy=Round(GraphicsHeight()/2) dx=Curve((MouseX()-gx)/4.0,dx,3.0/AppSpeed()) dy=Curve((MouseY()-gy)/4.0,dy,3.0/AppSpeed()) MoveMouse(gx,gy) camerapitch=camerapitch+dy camerayaw=camerayaw-dx camerapitch=math.min(camerapitch,90) camerapitch=math.max(camerapitch,-90) fw.main.camera:SetRotationf(camerapitch,camerayaw,0,1) ]]-- local tirespeed=-(KeyDown(KEY_UP)-KeyDown(KEY_DOWN))*2.0 car:AddTireTorque(tirespeed,0) car:AddTireTorque(tirespeed,1) car:AddTireTorque(tirespeed,2) car:AddTireTorque(tirespeed,3) steermode=0 if KeyDown(KEY_RIGHT)==1 then steermode=steermode-1 end if KeyDown(KEY_LEFT)==1 then steermode=steermode+1 end if steermode==1 then steerangle=steerangle+4.0*AppSpeed() elseif steermode==-1 then steerangle=steerangle-4.0*AppSpeed() else if steerangle>0 then steerangle=steerangle-4.0*AppSpeed() if steerangle<0.0 then steerangle=0.0 end else steerangle=steerangle+4.0*AppSpeed() if steerangle>0.0 then steerangle=0.0 end end end steerangle=Clamp(steerangle,-25,25) car:SetSteerAngle(steerangle,0) car:SetSteerAngle(steerangle,1) fw:Update() local campos=TFormPoint(Vec3(0,1,0),chassis,nil) fw.main.camera:SetPosition(campos) fw.main.camera:Move(Vec3(0,0,-10)) local t=TFormVector(Vec3(0,0,1),camera,chassis) a=-math.deg(math.atan2(t.x,t.z))+180.0 fw.main.camera:SetRotation(Vec3(15,CurveAngle(180+chassis.rotation.y,fw.main.camera.rotation.y,10),0)) carobject.turret:SetRotationf(0,CurveAngle(a,carobject.turret.rotation.y,10.0/AppSpeed()),0) chassis:Hide() local pick = LinePick(campos,camera.position,0.5,COLLISION_PROP) chassis:Show() if pick~=nil then camera:SetPosition(pick.position) end fw:Render() Flip(0) end chassis:Free() chassis=nil camera=nil ShowMouse()

If the name property is not handled in any special way in the script, then it is simply added to the entity keys.

1, 3, and 5, and of course uncompressed. I recommend using 5.

I got my idea working with spot lights! You can simply use a shadow mode of 2 to indicate an object or light should be considered "static". A light that has the static mode set will use two shadow maps; one for static objects and one for dynamic objects. In the image below, the walls and room are static, and the oildrum has the regular dynamic shadow mode set. As you can see, redrawing the shadow only requires 650 triangles. Without this feature, the whole room and everything in it would have to be redrawn any time something moved! Best of all, if the light moves or if any static object within the light's volume moves, both the static and dynamic shadowmaps are redrawn. The process is seamless for the end user. Dynamic lighting is usually dynamic, and baked lighting is usually static. I'm not sure what this qualifies as, but one thing is for sure...it's optimal! This will yield a huge performance increase for scenes with lots of point and spot lights, as long as those lights remain in a fixed position. You should avoid having lots of moving point and spot lights.

Vegetation is rendered with a highly specialized system that is designed specifically for drawing large numbers of static repeating objects. You would never be able to render 100,000 trees using the conventional entity system.

What price would you be willing to pay for models that are 100% converted correctly and ready to use in the engine, with a Lua script included that could display the weapons with animation, muzzle flash, and sound effects? It would be a Lua plugin for FPS weapons.

This is not possible.

The problem with using a physics body and forcing it upright is those forces have undesired effects. You start to understand them once you get into it. It's very very hard to get a controller to not slide down slopes, because the torque to right the body will have other effects. The solution I implemented treats the body as an upright shape with no capacity for rotation.

Use it on a mesh placed on the terrain, not on the terrain itself.

You can also use PayPal: https://www.paypal.com/xclick/business=orders%40leadwerks.com&item_name=Leadwerks%20Engine%202.3%20single-user%20License&amount=200.00&no_shipping=0&no_note=1&currency_code=USD

Off the top of my head it would be something like this: p=TFormPoint(Vec3(0,10,-10),car,nil) camera:SetPosition( Vec3( Curve(p.x,camera.position.x,10), Curve(p.y,camera.position.y,10), Curve(p.z,camera.position.z,10) ) ) camera:Point(car,3,1,0)

I just changed the cast shadows checkbox to a drop-down box with more options: disabled, dynamic, and static. Existing scenes are unaffected.

There is a chat page.