marchingcubes

So, after a couple of months of inactivity due to various life issues, I am back working on this project. What did I miss?

yep, the parenting bug has stalled my work on my project too

As shadmar says, the water height is a world attribute, currently i turn on my water post effect when the camera's global Y is below the water height. As far as detecting when the beaver is actually in the water for the purposes of triggering the swim animation (which is not currently hooked up in the latest vids) I use a piece of geometry conforming to the river/lake area which if the beaver is 'inside of', he will swim, and if outside, he will walk. This invisible 'water area' also serves as a navigation barrier for the bear, and can be used to confine the fishes' swim area.

Jumping isn't currently implemented.. will probably put it in at some point. Possibly in the next round of animation work I do. Even for a limited-scope demo like this there is so much work to do, in so many different areas that keeping a priority list and staying focused on what is most needed for a playable experience rather than getting distracted by a million 'nice-to-haves' is necessary. soundscape/soundtrack, for example, is higher up the list than additional character actions

I'm not sure what you mean by 'the mountain to turn to water'? Possibly thats where the camera dips below/into the terrain - I need to fix that.. but currently just an artifact of the way the camera is positioned relative to the player. I already have to raycast to keep the beaver's tail mostly clear of the ground, so I guess I will do something similar for the camera.

+1 I have a ton of objects, am nowhere near done adding them, and am finding the scene panel pretty weaksauce too. Please give it some love ASAP.

Heres another progress video: http://marchingcubes.com/beaver12.mp4 This one shows the 3 'levels' - exploration, crows/pinecones, bear/lake.

Been busy working on filling out the terrain and making zones for the levels

The 'asynchronous' implementation of X11 isnt really responsible for any issues in end-user UIs except for difficulty to sync application redraw with X11 server repaints, but this is never a problem for the applications themselves which just send x protocol messages whenever they like. It is just a huge problem for the x server to identify a 'ok this app is done updating so i'll copy its buffer to the screen' barrier. X11 is being replaced for many reasons, and this is definitely one of them, but i'm not sure the 'GTK is asynchronous' issue w/regard to updating widgets etc. is any more of a problem here than in any other event-loop-driven UI. I don't do any GTK these days, but I don't recall having to architect my GTK applications for an asychronous widget model.. The only situation I can think of that matches the description is if you are dispatching events, and expecting those events to be received and processed before the glib event loop has run. I am not aware of any UI system anywhere that processes UI events without relying on this type of 'asynchronous' queue mechanism. However, as far as I am aware, direct function calls to GTK widgets e.g. gtk_button_set_label() or whatever are entirely synchronous. Can you be more specific about what is problematic?

Yeah the multiple footstep sounds is definitely something that would make the experience better, and the current 'lame beaver' footsteps sound is not exactly good anyways.

fish havent been put back in yet - i havent done much to 'componentize' anything in my sandbox level, so a lot of things have to be reconstructed.. not sure if there will be fish on the first level anyway .. will probably raise the bottom of the river to make it shallower in the first section.. once you get through the first dam, there will be small fish, and on the last part (the lake) probably lots of bigger fish

After a bit of a pause in development, I am back working on reworking the map into something that can be played as a series of levels.. I kind of started with a blank scene so most of the functionality (or sound) from my 'sandbox' level isn't in there yet, but hopefully it will all come together quite quickly from this point on. http://marchingcubes.com/beaver11.mp4

Seems to be a bug in latest 3.4 beta - When I rotate a directional light, (either by dragging on the axes themselves, or updating the numeric fields), the visible axes displayed for the Directional Light in the editor do not change - though the angle of the light does. This makes it a little tricky to align the light source's direction with the sun in my skybox.

sewers looking good

And another tip - should you wish to 'expand' your terrain, e.g. create a small area and then embed that in the center of a large area, so your level extends further, you can resize the terrain 'canvas' e.g. to place a 256x256 terrain heightfield into the middle of a 512x512 area: convert /path/to/map.exr -interlace none -depth 16 -endian LSB -gravity center -extent 512x512 gray:/path/to/leadwerks.raw