lanice / elemate Goto Github PK

Create simple landscape which is not pure random but has some recognizable structures.

Add basic texturing and physx materials to the terrain.

... if you know the answer of how to raise out hand model without being offset to our cursor position.
Maybe a simple "Hold-Ctrl-and-scroll" (or similar) would be useful to do it in-game. If we dont raise the hand-position, we have to give PhysX the mesh, so elements collide with it.

Request for renaming the GodManipulator to GodNavigation:

• change 'Manipulator' to 'Navigation' because that's what this class does, the actual manipulation (in terms of world manipulation) will take place (or at least get handled) in the current named GodEventHandler.
• therefore...:

Request for renaming the GodEventHandler to GodManipulator

• see above for reasons
• additionally, with above naming we can create another EventHandler who takes care of handling events non-related to the game itself, e.g. invoking the menu. The advantage is, that the Navigation and Manipulator can be discarded when game loop ends while we can still hold the EventHandler for the menu and that stuff.

Open for discussion.

To get into interaction between elements, one suggestion: We realise element/particle behavior by scripting the emitters as follows (example):

• We have two emitters, one emits fluid water particles and one emits e.g. more solid/viscous particles
• When particles of both emitters interfere with each other, those particles will be removed from their emitters, and simultaneously a new emitter is created which has particles at the positions of the removed ones
• the whole emitter creation (with e.g. physx-parameters etc) is handled by a lua script which knows both previous emitters and the number of particles that interfered from each emitter.
• based on this, the script can determine the NEW parameters for the new emitter, which, as said, owns the colliding parameters

This is a suggestion based on the approach, that it would probably make no sense to have an object for each single particle (and probably ist not even 'simply' possible with physx) which parameters you could dynamically change.

(Could possibly solve #63 )

Open for discussion/alternatives.

Add a physics representation for this element.
It should probably consist of rather large blocks instead of particle dust.

It is possible to move the camera below the terrain when changing the pitch angle with the scroll wheel.

We will need to make some changes on the physicswrapper and particleemitter for our next implementation step, especially the user interaction and terrain/particle transformation.
Please let's collect some ideas here =)

-> release december 2013
There won't be any greater changes in our code, see https://developer.nvidia.com/sites/default/files/akamai/physx/Docs/MigrationTo33.html.
But hopefully this simplifies building on linux...

To initialize a new APEX Environment, there is need for an own UserRenderResourceManager and ResourceCallback.
Currently, there are nullobjects (nullobjectplaceholder.h) that override the abstract base classes. Of course, those Null Objects throw exceptions if they were requested like they would in PhysicsWrapper::step() while calling m_apex_scene->simulate(...).

To have a reference of how someone else did it, there are possible implementations in APEX-Examples. What a pity that these implementations are made with Direct3D.

It would be nice if someone with knowledge of OSG Buffers and stuff would take responsibility for this issue or at least give me a little hint ;)

Particles -> should work with physx fluid particles
Terrain -> add another texture to the base level.

Do the rendering in dedicated class.
Allow post processing.
Make render buffer accessible.

When pressing Alt+R without moving the mouse, the mouse moves anyway. Please look how to fix that.

We have some bugs in the rendering part:

• the shadow mapping is somewhat unpredictable, probably due to texture() calls during non-uniform control flow
• the shader reload does not work if the same shader file is loaded for multiple programs (currently phonglighting, depth_utils shader)

Integrate a scripting toolkit for flexible definition of element properties and interaction.

Possible languages: Lua, JavaScript (with QtScript?), Python

I think to proper handle incoming events (mouse clicks/movement, keyboard input, pretty much everything) it is almost indispensable possible to implement our own version of a Viewer (it could inherite from osgViewer::Viewer of course to simplify things).

To justify:
The osgViewer::Viewer itself is an osgGA::GUIActionAdapter, which is passed to an EventHandler (CameraManipulator or e.g. the one I set up for non-navigation related events) every time an event occurs.
Therefore, to don't mess up with encapsulation and stuff, passing e.g. the Game class around among the EventHandlers it is necessary that the Viewer itself implements methods or calls that can handle these things, because the Viewer itself (as the receiving ActionAdapter) will be 'passed' to the EventHandler anyways.

Have a look at e.g. https://github.com/openscenegraph/osg/blob/OpenSceneGraph-3.2/src/osgGA/StandardManipulator.cpp#L273 The actual event handling is doing some internal calculations followed by calling a method from the passed ActionAdapter (the Viewer), who then executes whatever should be handled (in the link above a redraw request). Our own Manipulator does exactly the same.

The problems occur when you want to be an event handled in a way the Viewer is not capable of, e.g. just adding a new Ball to the scene and having it properly updated and connected with PhysX. At this you have to implement your own Viewer if you, like I mentioned, don't want to mess with dependencies and things like this.

Questionable is though, what the new Viewer exactly should additionally be capable of, in terms of which classes should it has access to (Game? PhysicsWrapper? ...?) or which additional functionality it should get (to don't let it overgrow to a god-class-like thing).

Open for discussion.

spawn triangles in the particle branch. after some time the first particles vanish. then the first new particle is stuck right over the hand of god.

Create a sensefull Eventhandling structure and fill it with life.

• EventHandler gets all incoming events and handles META-events like ending the game or reloading shaders. Redirects other events to Naviation/Manipulator.
• Navigation: Navigation...
• Manipulator: Handling of events that cause in-world-manipulation like throwing elements, manipulating terrain etc..
  ref #40

Allow to change the terrain at run time.
First testing use case would be to change the height value at the "cursor" position.

Create stone where water and lava particles get mixed.

see #23

Add a post processing pipeline to support shadow mapping.
We could just copy paste the code from hpicgs/cgsee, but have to integrate it with the osg rendering.

When [space] is pressed, rotate the navigation back to its home position, but do not move it. (Like it was in the osg implementation)

Currently, the sound still remains where fountains were created. It has to follow the hand as long it is emitting.

• Calculate the bb of the hand.
• Check that the hand is above the terrain, at the bounds of the box.
• Create emitters at the center of the box

Draw the water particles as points into a depth buffer, apply blurring on depth (and normal) buffer, render the water with help of the depth buffer in screen space.

Currently i am at 25 fps on my (mobile) AMD.. without the water rendering.
There are some easy things to do/try:

• implement Early bailing in the shadow mapping
• integrate shadow mapping with color rendering path
• more laziness in transform calculations/setting uniforms
• ...

Improve particles to work with PhysX fluid particles.

Integrate libraries to load the hand object and textures.

• Assimp loader for the object
• libjpeg/Qt/... ? for texture loading

We need this for water rendering, shadows, etc...

The water particles (quads at the moment) don't scale with the zoom, e.g. if I zoom out, the quads should become smaller (I think so?), but they don't at the moment.

Currently, the ParticleEmitter doesn't delete old particles before reusing their indices. This leads to the console warning, and causes program crash when using "checked" physx libraries.

Set a light source to represent the "sun". Its position should depend on some kind of daytime. The light color and intensity should interpolate between white/blueish, red and black.

Enhance the LuaWrapper mostly by the possibility of registering C++ functions to Lua, so that you can call such C++ functions from within Lua scripts.

Also changes the function call interface (referring to m_lua as pointer to LuaWrapper instance):

• Without return value (void):

m_lua->call(functionName, Arguments...);

• With a single return value (int in this case):

int value = m_lua->call<int>(functionName, Arguments...);

• With multiple return values (with int and std::string as first two):

std::tie(value1, value2, ...) = m_lua->call<int, std::string, ...>(functionName, Arguments...); 

(std::tie for unpacking std::tuple)

Add a game interfaces for world independent interaction, providing a visualization for the inventory.
Later, we could also show game stats, like in game position/minimap(?), achievements,...

Put the particles into a vertex buffer and draw them as GL_POINTS. Everything else will be done in the shaders =)

Create an "interactable" counterpart of the rocky element, probably not with physx particles but some kind of rigid objects.

source available on https://code.google.com/p/osghimmel/

Because it seems pretty difficult to integrate APEX correctly into our environment without deep understanding how osg's render process exactly works, before we put even more effort into it (after many hours were put into it already) it might be reasonable to switch to another method of working with particles.

• PhysX can take care of the collision and detection of particle dynamics (like it does in APEX?), but emitters, lifetime maintenance etc. needs to be provided by the application
• Glow provides an easily configurable particle system, how exactly has to be worked out

• add a viscous fluid
• provide a glow effect for more realistic appearance

At the moment there is a little messing around with the rotation quaternion.

Also #56.

ref #40

Allow gathering of material to place it in the world as desired.

This will probably mean that we transform terrain into particles but prevent that they get back into the world. E.g. while holding a "gather" button, each vanished particle add some amounts of its material to the inventory.

Provide basic particle based element interaction

• Create particles where the Hand interacts with the terrain.
• Lower the specific terrain layer as needed
• Raise the terrain on particle destruction

We should create a class that keeps track of loaded shaders to update them when necessary (press F5...). It does not make sense to put all the shaders/programs into to game class.

And it's too much duplicated in initShader() code in the moment. A simple call like ShaderManagerClassThing::get("vertex.vert", "geo.geom", "frag.frag") would be nice.

When alternately rotation left and right, the camera moves backwards.

Ensure that water behaves "normal", also when not simulated by the physics.

It's probably hard to calculate large areas of water/fluids with the physics. Therefore we should add some routines that check that fluid terrain layers are never above the solids without being bound by them.

With #16 there comes a compiler warning:

> ...\FMOD Programmers API Windows\api\inc\fmod_errors.h(19): warning C4505: 'FMOD_ErrorString' : unreferenced local function has been removed (..\src\world.cpp)

Because the warning has its origin in the fmod sources we can't fix it directly in our code, however we could use something like

#pragma warning(disable: 4505)

at the top of world.cpp to surpress that specific warning... Don't know if it's a good idea?!

Split the terrain in tiles will increase performance when we have a larger game world.
Multiple tiles do not work in the moment, some matrices in TerrainGenerator seem to be wrong.
Also, transitions between tiles should be invisible.

• Adjust gameloop and Navigation such that navigation will be framerate-independent.
• Give World a Timer whose time diff will be passed to Physicswrapper in every step() call. This will let us manipulate the (in-game) time by only accessing the World.
• Physics updates should be called with something like m_world->update(), because the single update steps (Physicswrapper, Objectscontainer) are located in World anyway.