Horde3D

Thanks a lot for updating it!

in
egMaterial.h
MaterialResData
SampTexResI

but in __init__.py
class MatRes(object):
SampTexStr = 407
-> SampTexResI = 407
?

sellee: I've fixed this bug in the community svn. Thanks for the the report.

When installing the python bindings I had to make them aware of horde3d myself, since it was installed to /usr/local/lib by default and that wasn't where python assumed they would be. Not saying this is wrong, just possibly something to be aware of. The error message was anything but clear, but at least it led me to the right part of the source file.

When running the samples, I came across a few issues: app.py assumes the resources are in a directory starting with ../../. I had to copy the resources from the sourceforge repo and the python bindings from the community repo. This is a bit wrong, since the log output doesen't say the full path being used and there are no instructions for this as far as I can tell.

I also had to make some modifications to terrain.py to get it working, patch attached.

Applied patch and added warning message when library is not found as discussed in irc.

The path for resources can be set by using the "--content" parameter.

I'm trying to use Horde with Python on a Windows machine. I'm using r386 from the community SVN (which I successfully built in VS2010) and the most up-to-date version of the \Bindings\Python\horde3d\ and the \Samples\Python\ folders.

When I try running terrain.py, I get the following error:

It looks like the ShowOverlays function is in _init_.py (just below the line where the error occurs). Does anyone have any suggestions?

Looking at the H3D documentation, it seems like in fact that function is now called h3dShowOverlay (singular, not plural). So changing that line to say _showOverlays = h3d.h3dShowOverlay might fix it, although it probably would be a better idea to chane all of the instances of showOverlays to showOverlay, but that's the one that deals with the C function in question.

That was the problem, thanks.

It is exactly the other way round. The function was called showOverlay in Beta4 but renamed (and changed semantically) in the svn trunk.

Ah, sorry about that then. So I guess fnv is not using an up to date build.

On another note, does anyone have good suggestions on integrating a physics engine into a H3D app written in Python? Bullet doesn't have complete Python bindings, so I'm looking at ODE right now. Finding it a bit confusing but probably usable. I think Newton has Python bindings, but it's not open source which limits portability. What do you guys think is the best way to go about this? Should I just write my engine layer in C++ and use whatever libraries I like, then just use Python for actual application code? That seems like it could be a good option, but I just want to know if anyone's gone through this before or otherwise has an informed opinion on it.

Hi pekuja,

What are the C-bindings to bullet like? You might be able to make your own bindings the same way horde makes its bindings, by ctypes. I guess take a look at the ctypes documentation to see how it is used and dissect the python bindings horde uses to see how functions and data types cross over to python-land and then apply the same principles by studying the C bindings of bullet.

Making a thin layer over your stuff and then making bindings to that might be a better solution if you'd like your python code to talk to something a little higher level like game objects and components instead. There's a bullet physics extension for horde itself floating about which Volker wrote and I think it was Irdis who updated it to work with the latest horde. I guess just take it and extend it to how you want and then make ctypes bindings to this, or just use it to study how combining to two could be realised.

Good luck, I'll be doing a similar thing as well except with lua (unless I can get horde's game-engine to compile for linux).

_________________
-Alex
Website

Yeah, I might be able to do that. The one weird thing the Bullet C-API does is that it uses empty structs as handles. I don't know if that's a problem; it just seems strange. Also the C-API doesn't have a lot of documentation. Just some very basic Doxygen docs and a couple of simple example applications.


Yeah, I am indeed trying to do something like that.


Yeah, there is an extension, but it seems to have a more object-oriented design, which is harder to make bindings for as far as I know?


Let us know how that goes.

I think what I'm going to do is I'll look into improving the Python bindings for Bullet. There are some bindings already out there; they're just not complete yet. Probably easier to keep the layer between the libraries and my Python code relatively thin instead of writing big parts of my engine/framework in C++ and add Python scripting, which is another option I was considering.

It looks like the rename of h3dGetPipelineRenderTargetData (h3dGetRenderTargetData) in r247 broke the bindings. Also the docs could use the rename update.

Fix for the bindings(lines 581-598):

_________________
Paul

Hi,

is anybody working on this? This latest patch is not integrated into Community SVN branch

Normally Codepoet is updating the python bindings. I'm not very familiar with Python. While I was trying to integrate the patch I noticed that the multiplication with 4 seems to be useless, isn't it?


shouldn't it be:



Or is there something in python that prevents buffer from being initialized correctly if bufferSize is not divided by 4?