Pixel Perfect

Hopefully this will give BMax users a head start with path finding which will be a great thing as most people don't have this capability. I had a quick look at your tutorial NA, am I correct in believing you have to supply your own nav mesh for this, that is ... it doesn't create a nav mesh automatically for you from your level?

Looking forward to seeing where you go with this Aily, nice work!

This is a example taken from a simple NPC class in my (soon to be released) eki-one integration example project : void npc::update(void) { UpdateController(m_NPCController,m_fAngleOfForce,(m_fForce),0,0,15000,1,0); Animate(m_entNPCModel, fmodf(AppTime()/40.0f, (float) m_iCurrentAnimationLength), 1.0f, m_iCurrentSequenceId); PositionEntity(m_entNPCModel, EntityPosition(m_NPCController,1),1); RotateEntity(m_entNPCModel,Vec3(0,getFacingAngle(),0),1); } In this case m_fAngleOfForce and m_fForce are derived elsewhere from a velocity vector passed from the EKI One AI engine (path finding) and the getFacingAngle() function returns the angle the NPC is currently facing; again from the AI engine. In your case you would substitute these values with your own calculated (desired) values.

I think Theo is referring to a more balanced argument of the pros and cons of using either Mika, not that we'd ever want to accuse you of bias B)

This is how I move my NPCs. You can make your model a child of the controller but I wouldn't recommend that as I experienced problems doing it that way. Simply apply a force and direction to the controller and get its new position; then move your model to that position as Rick is suggesting.

You're welcome. You might try running your release build using ctrl-F5 (start without debugging) and see if that gets round the issue. Even in release mode using F5 on its own enables some of the debugging overhead.

I'd have thought the exact same loadScene function is being called by both Lua and C++ so I wouldn't have thought the issue is in the source code as that will be the same for both. I am using VC2008 and have not experienced any issues like this so I'm at a loss currently to explain what you are seeing.

Are you running your C++ app in debug mode and linking to the debug version of the leadwerks DLL? Not that I'd expect it to make that much difference but just a thought. Try running it in release mode.

I'm not entirely sure why, with a mass set, your NPC is not climbing the stairs. How are you moving your NPC? Is it using a character controller? Are you simply applying insufficient force to move your character? I take it if you are using a character controller that it has a suitable step height and slope angle set otherwise it wouldn't climb the stairs with the mass set to zero either!

Good illustration Richard. Just about anyone who has used 3DWS will have seen issues with light leakage or incorrect shadow casting due to problems with the way us beginners tend to construct of the geometry. Once these are understood it ceases to be an issue. Ambient light optimization is a separate thing but also necessary for accurate portrayal of reality.

Sorry for the confusion Glad we are all agreed that Josh needs to fix this

Well in my copy of 2.5 the grass colour still seems to be completely dependent on the base texture, the terrain layer texture appears to have no effect, nor the blend setting, on the colour of the grass!

That would tend to imply the wall is not casting a shadow (it's as if the wall is not there) as Josh is suggesting. Might be helpful to post a few screenshots just to make sure we are all clear on what the issue is.

I think what most people are expecting is that the grass colour reflects the colour of the terrain beneath it. That is, the combined blended colour of the basemap and the texture, not just the colour of the basemap as it is now.

Surely the grass colour should reflect the underlying texture or the blended result of the texture and basemap texture if there is one. I thought the whole purpose was the grass colour was meant to reflect underlying terrain colour!

Start your own thread ChrisV. It looked interesting!

The wikipedia states: This question and response from Creative throws some light on the matter (ref: Creative OpenAL EULA). I assume the questioner being named Josh is pure coincidence:

It's the usual pipeline Vickie. Via UU3D or using the conveters provided in the Tools directory of the Leadwerks SDK, in this case fbx2gmf.

Also DDS has hardware support on the graphics card, it takes generally less room on the cards video memory as it can be stored compressed and then expanded without using the CPU. So you get more texture storage on the card by using this format. By the way, if you are designing your game to be moddable then you might want to check the End User Licence Agreement first as there are some restrictions on moddable games. I'd run your basic idea past Josh at Leadwerks first before committing yourself to deeply as he has the final say on this. If it doesn't affect gameplay and is just cosmetic its probably ok.

I like the feel and atmosphere of this ... has that System Shock feel about it

I've found that Fragmotion does a better job with the FPS Creator .X format files than UU3D. UU3D has a tendency on some of them to drop vertex assignments on animations when reading the files in, causing issues with the animations. I convert mine first into another format using Fragmotion then use UU3D or one of the provided converters to convert to gmf.

All's well that ends well ... I can cope with losing a few hours worth of posts. These things happen from time to time.

Is that your own modelling then Vickie? Looks very Gothic as NA has already pointed out Do I take it from zaphos's comment that this is a port of a game you've already developed in realmcrafter?

Thanks Paul. Just saw your R.A.T.S. project, that's looking well cool.

Nice explanation Aily. I also use these types of techniques in my game engine. I have an underlying GameObject class that contains lots of virtual functions including an Update function which all higher level objects inherit from. All update functions are registered as part of the construction of the class with an application event which is triggered in each iteration of the game loop; automatically calling the update functions of all game object derived objects which exist at the time; so I don't even need to call them directly. The update functions control, as you say, the functionality of the object. Its a great way of working in an object oriented way and encapsulating functionality in an easily extendible way.