Josh

Half-Life 2 is the only Havok game I know I have played, and when you push objects in the game, the movement is extremely jittery. Maybe it has gotten better in recent years. There's been a pretty good case made by people wanting to use other physics libraries. I don't think I can support other libraries officially, because it is very hard to get all the functionality we have working with every physics lib, but I don't see a problem with other people implementing their own. I'll begin to design things with this in mind, and figure out exactly what it would entail to completely disable Newton.

Fortunately if I change this, any code that worked with byte ptrs should work with vec3 objects as well.

That's a pretty good idea.

I would create a new object with settings that control your game settings, in the same way the environment\atmosphere object controls global settings.

Yeah, TextHeight() is unnecessary since you would never care about the height of a particular string. You care about the height of the tallest letter possible.

I am not sure why I chose to use byte ptrs in BlitzMax. A Vec3 makes more sense to me, don't you think?

The controller/terrain bug was fixed. That's really neat. Who would have thought a few years ago that programmers would be able to slap a few assets into a program and get something that looks this good?

No, because I wrote the controller implementation. Maybe I can cap the max force that can be applied.

I would use particles with a refractive material.

If you are doing a lot of AI or other processing code, a compiled language will be needed. If you are doing something simpler, Lua will be fine. You can also use a combination of a compiled language together with Lua.

How can mysql perform a fast query for an object within a range of an X/Z position? Y position can be ignored, since most games don't have much of a vertical component. I have tried for a long time to think of a way to sort objects in two dimensions, but it doesn't seem possible without putting them into some kind of grid structure.

Yes.

That's probably accurate. It's probably impossible to make a networked system with the problems I described.

And it's better to use require() than dofile()!

For the crawler model, I ended up using the Reset() function to get around the problem of repositioning the controller. This is written for multistate Lua, so it needs some small changes to work: dofile("scripts/base.lua") dofile("scripts/math.lua") dofile("scripts/linkedlist.lua") AINodeScanRange=100 AnimationWalk=0 AnimationIdle=1 animspeed={} animspeed[AnimationWalk]=0.036 animspeed[AnimationIdle]=0.01 dummynode=LoadModel("abstract::info_ai_node.gmf") if dummynode~=nil then dummynode:Hide() end function Cleanup() if dummynode~=nil then dummynode:Free() dummynode=nil end end function Reset(model) local entity=entitytable[model] if entity==nil then return end entity.controller:SetPosition(Vec3(model.position.x,model.position.y+0.9,model.position.z)) entity.angle=model.rotation.y+180.0 model:SetTarget(nil,0) end function UnlockKeys(model) model:SetTarget(nil) end function SetKey(model,key,value) local entity=entitytable[model] if entity==nil then return 1 end if key=="enabled" then if entity.controller~=nil then if value=="0" then entity.controller:SetMass(0) else entity.controller:SetMass(10) end end end return base_SetKey(model,key,value) end function Spawn(model) local entity=base_Spawn(model) entity.angle=model.rotation.y entity.controller=CreateController(1.8,0.45,0.25,45) entity.controller:SetPosition(entity.model.position) entity.controller:SetRotation(entity.model.rotation) entity.controller:Move(Vec3(0,0.9,0)) entity.controller:SetCollisionType(1,0) entity.controller:SetMass(10) entity.currentanimation=0 if entity.model:CountAnimations()<2 then --LoadAnimation(entity.model,"abstract::actor_cartoon2.gmf") end function entity:ChooseNewNode(ainode) local nodes={} local i local count=0 local newtarget --Create a table of all AI nodes this node is connected to for i=0,15 do nodes[count]=ainode:GetTarget(i) if nodes[count]~=nil then if nodes[count]~=self.prevnode then --avoid doubling back count=count+1 end end end --Choose a random node if count>0 then newtarget=nodes[math.random(0,count-1)] self.model:SetTarget(newtarget,0) else --no node found, so let's just use the previous node --self.model:SetTarget(self.prevnode,0) self.model:SetTarget(nil,0) end --if ainode~=nil then self.prevnode=ainode --end end function entity:Update() local dx,dz,p local target local ainode local closestainode=nil local closestdistance=10000000.0 local perfectangle local noderadius local movement=0 target=self.model:GetTarget(0) --b=CurrentWorld().entities --If target is nil, we need to choose an AI node to move to if target==nil then if dummynode~=nil then for ainode in iterate(dummynode.reference.instances) do if ainode~=self.prevnode then if ainode:Hidden()==0 then d=EntityDistance(ainode,self.model) if d<AINodeScanRange then --dismiss nodes that are far away if PointVisible(self.model.aabb:Center(),ainode.mat:Translation(),0,COLLISION_AILINEOFSIGHT)==1 then --line-of-sight test if d<closestdistance then closestdistance=d closestainode=ainode end end end end end end --Found a valid AI node, so set the target if closestainode~=nil then self.model:SetTarget(closestainode,0) end end end --We have a target node to move to if target~=nil then --Figure out angle between actor and target dx=target.mat.tx-self.model.mat.tx dz=target.mat.tz-self.model.mat.tz perfectangle=math.deg(math.atan2(-dx,dz)) --Calculate angle between the actor and the target and adjust as necessary. --This provides a smoother more natural movement, and the character takes --the easiest path instead of pointing straight at the target node. local noderadius=tonumber(target:GetKey("radius","4.0")) local noderange=tonumber(target:GetKey("range","1.0")) --Get the distance between the projected entity vector and the node model:SetRotation(Vec3(0,self.angle,0),1) local d=LineCircleDistance(model.mat.tx,model.mat.tz,model.mat.tx+model.mat.kx*100.0,model.mat.tz+model.mat.kz*100.0,target.mat.tx,target.mat.tz,3.0,1,0) --If the distance is over the radius, increment the angle towards the node local turnradius = 1.0 turnradius = turnradius+clamp( 90.0*(1.0 - clamp( d/1.0,0 ,1) ),0,10 ) if math.abs(d)>noderadius then self.angle=IncAngle(perfectangle,self.angle,turnradius*AppSpeed()) end --Choose new node when target node is close enough --We only care about the 2D distance on the XZ plane if math.sqrt(dx*dx+dz*dz)<noderange then self:ChooseNewNode(target) end movement=2 self.currentanimation=0 else movement=0 self.currentanimation=1 end --Update the controller self.controller:Update(self.angle,movement,0,0,40,1) self.model:SetPosition(self.controller.position) self.model:SetRotation(self.controller.rotation) self.model:Move(Vec3(0,-0.9,0)) self.model:Turn(Vec3(0,180,0)) local frame=AppTime()*0.08 frame=math.mod(frame,130-70)+70 if EntityCulled(model,fw.Main.camera)==0 then self.model:Animate(frame,1,0,1) end end return entity end function Update(model) local entity for model,entity in pairs(entitytable) do if entity.model:Hidden()==0 then if entity.enabled~=0 then entity:Update() end end end end function Kill(model) local entity=entitytable[model] if entity~=nil then if entity.controller~=nil then entity.controller:Free() entity.controller=nil end end base_Kill(model) end

I meant a heightfield where there is just a pointer to the height data that can be changed at any time. PhysX heightfields can't be dynamically updated: http://developer.nvi...?showtopic=3548

You should talk to the guy I had make the soldier model.

If anyone wants to make a desk like below, I will add a script to give it physics. The drawers should be separate pieces. A physics shape needs to be created for the desk and each size drawer you use. Each drawer can be a limb in the mesh file, with a name like drawer1, drawer2, etc. The pivot of the drawer should be in the center rear of the drawer. The drawer physics shape should consider this point the origin...the draw physics shape will be loaded from the .phy file and connected at this point with a slider joint, with limits. After I write the script, you will be able to grab the drawers in the editor and pull them open to see what is inside. It might be easier to just make all the drawers the same, since it will probably be a little confusing to set up at first. This is what got me thinking about this: http://www.youtube.com/watch?v=Ux4OwkS9ybA

That's not feasible because each physics library is so different. PhysX does not support heightfield data. A terrain has to be made out of a mesh, and editing the terrain in real-time like we do is not possible. So what is everything considered "disabling physics"? Generation of the .phy files? What about raycasts? They use the physics system. Should they be disabled? What should happen if the user calls a raycast command when physics are disabled?

I think it's very useful for debugging and adjusting the engine for individual needs, but it does require a fair bit of courage. Now that the engine has Lua and is pretty stable I think it's safe to branch off with your own version of the source.

The only time I have seen this occur is when a really detailed collision shape was used with lots of small triangles, and it was a situation that should not have been allowed to happen.

You can also compile files into your EXE, with some languages.

The most I have seen is some boxes falling. I have not seen: -Selective collision system. -Interpolated physics with constant update speed. -Joints -Vehicles -Terrain -Character controllers -Any of the features that motivate people to look at PhysX in the first place. So the most I have seen is some experimental stuff that doesn't have nearly the same feature set as our current implementation. I'm not sure what the motivation is to pursue these alternatives.

Well, we know something is funny in your code. What kind of a rendering setup are you using? Framework, or something of your own? Have you customized the renderer or done anything that could affect the depth buffer?

Enable z-sorting in the material.