Some further testing of my Root Driven Motion with more complex animation and movement. I'm happy this is working as I want it now.

Time to decide on a final animation pipeline and ensure it's robust ... my least favourite aspect of game design!

Very nice Ian and a happy girl

Lovin the ram in the background...lol but beautiful work! the bulrushes .. lilly pad abd beautiful texture works are amazing!

Can I ask how high poly are your models that you are using? (the church btw nice!)

still kinda unsure on how high poly i can make models and how the engine renders them and render lag wise...

but keep up the good work!

Thanks Kallyanna.

In answer to your questions here are some typical sizes (polygons) of the models in the village:

Church 5023
Blacksmiths 7344
Inn 10878
Medieval House 14720
Oak tree 7528

Esenthel seems to handle polys quite well. I have tried individual models of sizes up to 164000 and it renders them with good frame rates.

I would recommend always using multiple Levels Of Detail on sizable models though. I generally use 3 LODs per model. The Medieval House I mentioned above for example has:

LOD0 14720
LOD1 8248
LOD2 2874

This helps maintain the frame rates as the scenes build in complexity and overall polys.

Generally a good idea to think about the textures too and try and combine textures into one file where possible to reduce draw calls.

View distance and dynamic shadows have a noticeable effect on frame rates, as does lots of lighting (probably mainly the shadows again).

High density vegetation tends to kill frame rates too, you need to LOD these and also keep it sparse or ensure you only render it over shorter distances.

Animated characters in my game tend to range from 2000 for background characters up to 12000 or so for main characters.
I'm sure you could push that too but I haven't needed to yet!

I believe the engine would greatly benefit from Advanced Occlusion Culling and Hardware Instancing support but with careful level design and LODing you can keep the frame rate acceptable with modern graphics cards.

Thanks for your reply hun

Yeah those are about the amount of polys im using right now, also 1 LOD for certain ones. I was going to see how much I could push the engine to the limit with a model to get a rough idea oh how much it could handle

"models of sizes up to 164000 " WOW yeah not even made a model that high poly yet...lol but its good info to know for the best optimized game play.

Also the vegetation was something else i was wondering about.. how much is too much and so on, since im only using planes for them and the built - in grass movements I wasn't sure if i needed to LOD them or not.


TY SO MUCH again for the info and your reply!

also keep up the good work!

(05-15-2015 08:08 PM)Kallyanna Wrote:  ...
Also the vegetation was something else i was wondering about.. how much is too much and so on, since im only using planes for them and the built - in grass movements I wasn't sure if i needed to LOD them or not.
...

If you're using simple planes then no, there is no need to LOD as that's probably the smallest poly representation you could have. In these circumstances frame rate hits are more about the sheer quantity of objects being rendered rather than their size so gains can be made by grouping objects together into larger collections and these could be LOD'd with a single billboard object.

Of course you can just keep the numbers low and reduce the draw distance to avoid poor frame rates but that is becoming almost 'old gen' as many modern engines are now able to handle high vegetation density which brings about increased user immersion with the more realistic scenes game designers are able to generate.

It's to partly get round this that I've been arguing for Hardware Instancing which helps reduce the amount of draw calls in these situations. It's been on the Esenthel Roadmap for more than the last two years that I know of, along with Advanced Occlusion Culling, but has never made an appearance yet.

Occlusion culling might really help here to as there is no point in rendering thousands of grass objects for example if they are obscured (occluded) from the camera by something blocking the view. Occlusion culling can be expensive though so any gains really depends on the circumstances.

I've been having a break from development whilst waiting for my Perception Neuron mocap system and also catching up with some games I've never played before, namely Witcher 2 in preparation for playing Witcher 3 which is installed and waiting!

Unfortunately, the delivery of the mocap system has been put back significantly due to reported manufacturing issues so I'm leaving the animation side for now and moving onto my next phase of development which is to code in a Camera Control System for cut scene use.

My EKI-One AI system has a nice Plot Line facility which allows you to produce multi-line flow chart control of agents on a time line. So my design involves the creation of a virtual agent Camera Director which can have its own time line and issue my own defined Camera Control Actions as appropriate. These would be sent as Events, with relevant data, to the game engine to implement.

I'm hoping this will give me sufficient control over the Camera in scenes to produce cinematic type camera effects. Some of the potential Camera Actions I've identified so far are as follows:

Static Follow:
This has the camera remain fixed in a given position and simply rotate to always keep the target in view.

Follow:
This has the camera placed in a position and then maintain the existing distance/angle from the target subject as it moves. The speed being determined by the target.

Rotate:
This has the camera placed in a position and then rotate around the target object producing a orbital view of the target. The rotational speed would be a configurable item.

Pan In:
This has the camera placed in a position and then maintain the target object in view as it moves in towards it at a predetermined configurable rate.

Pan Out:
This opposite of the above.

The positions could be named waypoints placed within the level design or actual co-ordinates specified explicitly within the plot line design.

I'm sure the need for other Camara Actions may come to light once I start playing with the system and refining it. A specific Camera Action for conversations might also be worth while to automate subject facial focus during conversations.

Hoping this works out in practice as again I have never really done anything like this before. We shall see!

Sounds really cool. Will be really nice to see the progress on this. Are you going for a Camera manager containing instances of subclasses of a custom camera?

Cheers

(07-12-2015 11:36 AM)rstralberg Wrote:  ...
Are you going for a Camera manager containing instances of subclasses of a custom camera?

On the game engine side yes, there will be a Camera Manager of some sort offering various Camera handling options triggered by the incoming event data. I haven't given too much thought to the detail yet as I've been concentrating more on the AI Engine side and ensuring I can get all the camera data events synced in with the actors motion in the cut scenes. I started on this last night and so far it's looking ok.

Will definitely be a two phase development with the AI side being the first phase, completed once I have all the events being received and translated successfully on the engine side. The second stage being the Camera Manager and the coding/testing of the various camera motions.

I have the Camera Control on the AI side pretty much designed now and the basic mechanism tested.

Below is a screen shot of the Plot Line Editor showing a series of Plot Lines I put together some time back for automating Change Of Guards.

Essentially, the ambient AI routines I wrote for the Village includes four Wall Guards that patrol the fortified walls enclosing the village. Each is
assigned to one of the four sides and patrols that wall walking forwards and backwards stopping at waypoints along the walls and turning to survey the
countryside before continuing their patrol. This continues unabated until, randomly triggered within a time range, a replacement guard is despatched
from the guard house to replace one of the patrolling guards (again randomly chosen).

The Plot Line shown here controls this Change Of Guard and the Guards chosen are only known at run time as they are randomly chosen from available guards
that fit the Roles. The Plot Lines define how the currently Patrolling Guard returns to his start position and awaits the replacement guard who walks
from the guard house to meet him. Upon arriving within a given distance he stops and both guards turn to face each other and a hand over conversation
takes place between them controlled by speech Actions on the time line. Once complete, they swap places and the original patrolling guard exits and
returns to the guard house leaving the new guard to continue the patrol duties.

When integrating camera control I needed to deal with situations where the camera position and its target would be known at design time (such as set cut
scenes within the game) but also deal with these more dynamic situations when the ambient system chooses the actors at run time to fit the predefined
roles and I have no way of knowing beforehand which actors or which of the four possible locations will be used during any instance of this activity.

I've achieved this by adding a virtual Camera Agent that can be added to the Plot Lines and a series of Camera Actions that can be added within the Plot
Lines to sync in with the defined actions for actors in the scene. Dynamic construction of the target and camera position is achieved by passing the
target Actor (say the replacement Guard in this example) as a parameter to the Action and having the Action script determine that the parameter passed
is an agent type and find the closest camera waypoint to this actor. Both bits of information can then be passed to the game engine to invoke the
positioning of the camera and the target direction by virtue of the target actor.

Conversely, where the design is known at design time my mechanism allows for a Camera Config object to be added as a prop and passed to the Action.
The action will then identify this and extract the camera position and target directly from the config object and pass these to the game engine. These
can be explicitly stated or again point to waypoints/actors.

   

An extract from my debug output to my engine log file shows the results of the dynamic parameter passing as processed by the Camera Action script @
22:27:46 ... approx. 4 minutes into the simulation:


The Camera Action script (which ever is chosen) then simply raises a Camera_Control event and passes the Type, Position and Target Position to the
game engine to handle.

The game engine side is the next to be coded but will have to wait till I come back from holiday in three weeks time. I'm pleased with the progress
so far though!

Decided to load MS VC++ and Esenthel on my Asus Transformer notebook and bring it on holiday. It will only run my game at between 5 and 20 fps but at least allows me to continue development.

So between exploring rock pools on the beach with my kids I've managed to code my camera manager and implement the first of the camera control modes, namely the cameraStaticFollow, which I'm happy to confirm is working well.

Being able to control the camera from Plot Lines will make a huge difference to the visual quality of the game.

Of course Esenthel has to join you at the holiday. Be sure that the poor little one don't get to sunburned though

lol ... we would welcome the chance to get sunburnt! We haven't seen much sun as yet, not that it's stopped us getting out and about

Coding has been confined to early morning before the kids get up, that's the only time I stand a chance

Game development continues:

With the underlying mechanics of my camera control working I need to expand it now to support all the camera control modes I envisaged.

I want to direct my attention next though to game saves and loads, ensuring I have that fully operational before getting deeper into game play and mechanics.

I'm expecting my Perception Neuron (mocap system) shipping notification email any time soon now so want to try and finish any outstanding coding prior to its arrival; as I'm sure that's going to take up a considerable amount of my time once it's here.

In the meantime I thought it was about time I designed an intro and menu system for the game. It's just using a placeholder font for now but otherwise the basic mechanics are in place:





Esenthel makes it so easy to do what I need to ... it's a superb engine and a pleasure to work with

Fantastic. You have really got an atmosphere of old time and nature there. Very nice