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

I have had leadwerks running on my machine at work with a quadro K4000.. didn't notice any issues, however this was on Linux. Its quite easy to imagine Avid would work just fine without graphics drivers, so suggest installing latest NVidia drivers for the card.

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.

More info: it seems, in the editor, these parent/child relationships work as expected - when i move my camera in the editor, my child object moves with it. In-game, the parent/child relationship seems non-existent when the parent object's position is set with SetPosition()

I see this too.. Interestingly, objects dragged in the scene tree to be children in an older build of the editor (Couldn't say which one) work correctly - e.g. I load an old map where a sprite is a 'child' of the camera, and it behaves as expected. In the latest Leadwerks (3.4beta), adding an object as a child of the camera in the Scene tree has no effect on the objects position or orientation, regardless of how the 'parent' camera is moved.

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

Hi, I was reading the docs for ForEachVisibleEntityDo and noticed that mention is made of an AABB in the docs, but does not seem to be relevant to this function (it uses the camera). The example code also defines, but does not use, an AABB. - this would appear to be a cut n paste from ForEachEntityInAABBDo() By no means a major issue, but I thought i would report it http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/world/worldforeachvisibleentitydo-r506

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?

YouGroove: I'm not sure an open source editor would yield immediate benefits - I mean, this is commercial software we all paid for. If we wanted to develop our own editors, we would probably be doing that. That being said, I would be interested in helping out if the editor was open source. Personally, I am hoping things will improve quickly. For my purposes, Leadwerks on Linux has been easy and fun to use.. Possibly i'm the only happy Leadwerks Linux user, but at least theres one of us?

YouGroove: I think there are plenty of us Linux users active on the forum.. These threads are obvious proof of that. I think it's easy for these issues to turn into flamewars, and it is certainly true that building software that works seamlessly cross-platform is never all that easy - but as a Linux user, I too would appreciate software that works as it is supposed to.

The only slight problem with xdg-open is it needs environment variables set to bind it to the user's current desktop session.. It is likely those variables will be present in the shell that spawned Steam/Leadwerks, but depending on how you invoke the process, those variables may not be passed along.. and if they are not present xdg-open will fall back to its 'generic' mime database instead of invoking the gvfs-open/kde-open handler, which can cause confusion if you have set a default browser in your desktop environment but xdg-open has a different one in its 'generic' database of mime type handlers e.g. printenv | grep XDG XDG_SESSION_ID=1 XDG_SESSION_COOKIE=1874c2ff359fcb03bb02ab5152dbcc09-1424239005.811223-1876517971 XDG_RUNTIME_DIR=/run/user/1000

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

Look man, this is the *constructive* linux thread. I have no idea how effective you think this passive-agressive **** is at getting the bugs in Linux Leadwerks fixed, but if you were trying to find an effective way to make me (and I can hopefully assume every other rational human on this forum) to consider you a total jerk, you won! Congratulations!

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

typing '\' and clicking the search also crashes leadwerks on Linux.

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.

I have pmed alrusdi with the patch.. its actually just a one-liner. If anyone else in interested (if you are getting oddball deformations in actions other than the first on an exported mesh): in armature.py 33c33,34 < self.matrix_basis = self.animations[0]['keyframes'][0] --- > self.matrix_basis = self.animations[-1]['keyframes'][0]

Agreed, I had not really considered an approach other than 'do all the things myself'.. Presumably this makes even the 'official' Leadwerks model packs difficult or impossible to work with?

I use separate named actions in blender (I have walk, swim, idle, die cycles), rather than animate all my actions in a single sequence and break it up into chunks using frame offsets in leadwerks. the exporter has an 'all actions' option which needs to be enabled for this to work. I did have a number of problems with bone/vertex weights, and had to modify the exporter code a little bit to get multiple actions exporting correctly (had issues with bones deforming the mesh in strange ways), but i've never seen anyone else report this as an issue, and I use a very bleeding-edge version of blender so wasnt sure if it was just that - I'm not at all sure i'm fixing the problem i see in the 'right' way - but thats how I do it. As long as weights are normalised, there are no unweighted vertices, and model and skeleton have no translation/rotation I can get multiple animation cycles per character into leadwerks and it all 'just works', no need to do anything to the model in the viewer. I see the author of the blender exporter is back on the forum and josh is looking to get some work done so I will touch base with him and see if my multiple actions patch is useful and if so get it into github.