I've updated pyogre. It is now based on ogre 0.15 (will work on 0.15.1 soon).
The build system can now handle both release and debug build. For those upgrading, be sure to delete your build/ directory and read the build instruction carefully.
[EDIT: regardless of what the text say above, this is the lastest available version pyogre based on ogre 0.15.1]
Notes that ogre demo media are different than the cvs media (for reason beyond my understanding the bsp level is not included in the CVS).
IMPORTANT: it is still very experimental, even though it seems to work (at least for monsterkodi, see kork). I'm still surprise that it doesn't crash...
If someone can give the least of missing dll on computer without visual studio, I'll include them
-- tisba
Last edited by tisba on Mon Jan 03, 2005 9:37 pm, edited 2 times in total.
tisba wrote:Thanks. I had to take a break from ogre to work on cppunit 2 .
Cool! I had no idea you were the main man on CppUnit. I use JUnit a lot at work, and have tried to use CppUnit a little in Ogre (difficult because of the visual nature of the results, but you can see an attempt in ogrenew/Tests/OgreMain anyway ), so nice work!
tisba wrote:Thanks. I had to take a break from ogre to work on cppunit 2 .
Cool! I had no idea you were the main man on CppUnit. I use JUnit a lot at work, and have tried to use CppUnit a little in Ogre (difficult because of the visual nature of the results, but you can see an attempt in ogrenew/Tests/OgreMain anyway ), so nice work!
Thanks. I've have maintaining that beast for a few year. You can not really understand how much c++ compiler have progressed until you have worked on a project like this that attempt to support old compilers.
Anyway, for testing ogre can take advantage of the multiple implementations of the RenderSystem (dx7, dx9 and gl): render the same scene with the three renders and compare the result. There's probably some way to compute image "distance" to do this automatically. Then come up with a generic scene format and take snapshot at specific time.
I finally got the RaySceneQuery working . The camera now follow the terrain in the terraindemo!
In addition to that, I finally reproduced the virtual function overload resolution issue in a simple test case. I'm currently working on correcting pyste to fix that.
trying to runthe precompiled pyogre in linux (ubuntu 4.10) and I get the following error
Traceback (most recent call last):
File "celshadingdemo.py", line 2, in ?
import localogre as ogre
File "/home/jovian/games/pyogre_20041203/pyogre_20041203/python/ogre/demo/localogre.py", line 4, in ?
from ogre import *
File "../../ogre/__init__.py", line 1, in ?
from pyogre_ import *
ImportError: No module named pyogre_
ideas on whats wrong and/or how ot fix. I have pyogre working in windows however my main development is in linux .
as a fyi th cloth and lighting demos crash on me in windows however.
Glad to know it's working somewhere else. I'm working on getting the lightning demo to work (the shared_ptr are giving me trouble).
Where did you get the precompiled linux version ? The precompiled version I'm posting is for Windows only. pyogre_.pyd is a dynamic library and is platform specific.
@tisba: I mean no disrespect, but I'm wondering what is the point of a python to ogre binding? I can see RAD perhaps... I'm just curious about the rationale.
"Experience: what you get when you didn't get what you really wanted."
"...I've found is easily translated into C++ later, if needed..."
Hmm, are you describing "hand editing" python code to C++ or are the scripts compilable? I've seen some efforts to compile scripts to binary but I've never been able to get it to work. That would certainly make the python/Ogre bindings very useful!
"Experience: what you get when you didn't get what you really wanted."
This rocks! I downloaded the full archive and ran it on my XP SP2 box using the OGL renderer. Very impressive! After examining some of the Python scripts, it looks like the Python/Ogre marriage was meant to be! Call me a PyOgre convert!
Now, to build something cool! MUHAHAHA!
"Experience: what you get when you didn't get what you really wanted."
no woring linux version I downloaded the windows and was tryng to get it to work in linux. I realized it was a fat chance thing but was hoping ot get it to work.
CodeMeister wrote:This rocks! I downloaded the full archive and ran it on my XP SP2 box using the OGL renderer. Very impressive! After examining some of the Python scripts, it looks like the Python/Ogre marriage was meant to be! Call me a PyOgre convert!
It's written with pyogre . Just be warned that the pyogre still have an experimental status. That being said, it's probably a very convenient way to quickly discover ogre without having to create c++ project
E:\Documents and Settings\NorME\Desktop\pyogre_20041203\python\ogre\demo>python
lightingdemo.py
Traceback (most recent call last):
File "lightingdemo.py", line 1, in ?
import localogre as ogre
File "E:\Documents and Settings\NorME\Desktop\pyogre_20041203\python\ogre\demo
\localogre.py", line 4, in ?
from ogre import *
File "../..\ogre\__init__.py", line 1, in ?
from pyogre_ import *
ImportError: Module use of python23.dll conflicts with this version of Python.
Either get the sources and recompile them with the Python 2.4 lib (hoping it will compile (link) without problems) or use Python 2.3 instead (I would do this last one, as it is very easy to have different python versions side by side).
I tried to give a linux port a shot but I stumbled over GCCXML because it doesn't recognise gcc builtins as such in the system headers provided with the compiler. And these are inevitably included by Ogre and so pyste runs into problems when executing GCCXML.
If anyone knows anything about this problem, I'd love to hear about it.
