Community Project - Techdemo - Framework available
bharling
15-04-2007 12:25:33
Hey,
How would the community feel about a collaborative tech-demo project, to show off python-ogre and ogre in general? I hear a PO 1.0 is not far away, and I feel Andy and the team's work deserves some celebration!
I'm simply thinking of a rolling demo, or something with very simple game dynamics, but concentrating mainly on producing some nice eye-candy to show off the engine. This, I think, would also create a good opportunity for people to learn more of the materials and particles scripts, shaders etc. which is an important part of ogre development. I'd imagine some physics integration as well would not be a bad idea. I'm quite good with blender as I imagine many people here are, so creating nice content shouldn't be hard.
Of course, we'd release it all under a gpl licence, and have it serve as something of a tutorial project for new users.
I'd gladly host it while in development, although I dont have any versioning system installed on my website.
Well, I have a few ideas of my own, but I'd like to hear ideas from the floor first, thats of course if anyone is interested in being involved
cheers,
Ben
Game_Ender
15-04-2007 17:16:04
I think any tech demo should try and start by building a clearer framework. One that separates at the handling and initialization of the separate libraries Python-Ogre works with. Having them all mashed together with a slight tangle of framelisteners mixed in is confusing.
bharling
15-04-2007 22:13:54
I agree, seperate out and simplify, but I think it should be a pretty self contained project. I mean, clear and well commented with everything transparent and readily available (no linking to the sample framework), but definitely geared in one project direction, to sort of say 'This is how
We did it ..', hopefully inspiring others to do it '
Their way ..' if you get what i mean
I've got a serviceable framework of my own running already. Its not optimized and features no physics yet, but is very expandable. I'll gladly trim the fat from that and re-organize it a bit to serve as a base for this project.
willism
16-04-2007 17:19:20
Just a few weeks ago I was thinking of proposing a similar idea. I would love to participate in a group project with the Python-Ogre community. Ideally, I'd like to see a little game that has some simple physics, multiplayer capability, sound effects, and of course great 3D graphics. Here are two game ideas that have been bouncing around in my head for a while:
Bumper boats: Each player controls a little boat with a powerful engine and elastic bumpers. Knock other boats around in places like a tropical lagoon, a wetland swamp, or a giant swimming pool. Have obstacles and interactive objects in the water like buoys, docks, giant beach balls, icebergs, etc. Possibly have different game modes such as racing, capture the flag, giant beach ball soccer, etc.
Food fight: Provide various settings ranging from a school cafeteria to some fancy-pants exclusive restaurant, throw food at other players, and avoid getting hit. Tip over banquet tables and crouch behind them for cover, etc. etc. You get the idea.
bharling
16-04-2007 17:54:19
Yo
yes i was also thinking to demonstrate multiplayer in the demo, however on the flip side, that does open up a whole new can of worms which could really delay us in producing something. You're right though, it would be really great to show off some multiplayer antics, as python is kinda famed for its easy conectivity.
like your ideas for games as well, particularly the food fight! I should say though, that i kind of envisaged this being a small project, not too ambitious. I mean kind of like the stonehenge demo on the main site. Not saying I particularly like that demo, but we could easily do something along those lines, but in overdrive if you get what i mean
If we're going to do this, i think it would be great to try and finish it to co-incide with PO 1.0 final, although by the speed of development so far, that could be tomorrow ..
willism
17-04-2007 15:59:35
Wow, I think I almost completely misunderstood your first post
I do have a history of being a little too ambitious. Ok, here's an idea that's more like a DEMO:
Create a scene with a landscape, some water, and a little coastal town. Fill it with entities that move around and interact with their surroundings in different ways, e.g. villagers wandering around town, birds flocking in the air, clouds that drift by, schools of fish under the water, people rowing boats, etc. Then define the behavior of the camera with a number of different states, such as "Watching town marketplace" "Flying through clouds", "Skimming water's surface", "Bird watching". Pick a random state to start in, then every 30 seconds or so switch to a new state. Make a smooth transition to the new state. For example, one moment it's up in the sky flying around with a flock of birds, and then it decides to check out a school of fish, so the camera does a nose-dive to look straight down into the water.
If we set up a good framework, the different entities and states could be fairly independant, such that the initial version might only contain a few different things. Then as it matures, people could contribute new entity behaviors and new camera states.
bharling
17-04-2007 20:50:24
lol, I'm not saying they are too ambitious, just trying to suggest a timescale as a constraint to the project, which will seriously help to get it done.
I like your idea for a demo, quite close to what i had in mind. I was thinking about normal-mapping as much as possible, and trying to work out some interesting lighting, in a context much like you suggested.
well, ergo a framework, I have started chopping up my own one, and am probably about half-way to releasing something for anyone to play with. Below are the features I hope to include (much of it I have already done):
Application - self-contained, set up with a release friendly folder structure.
Object oriented 'actor' class - sub-classable to make characters
setup with rudimentary behaviour, maybe a little ai
DataManager class - controls game flow, loading etc.
XML scene loading - through dotscene, part of datamanager
config parser to scripts for actor placement
EventManager - part of the datamanager. a heapq event system,
process-centric rather than object-centric i hope.
Newton physics
Main Menu structure - overlay and framelistener
ingame frame listener - at least one
one or two example actors
setup for shadows, and compositor support
As I said, I'm just really cutting the fat from a previous project, so I think i will have some code people can use in the next few days. The stuff I haven't built yet is the physics support and main menu.
Game_Ender
17-04-2007 22:02:40
Make sure to run your own main loop instead of using frame listeners, if you are trying to make better example application that would be the way to do it.
bharling
17-04-2007 23:42:23
I sort of have a combination for that:
the app has a mainloop which controls all updates to in-game content.
there are also framelisteners for the menu (to navigate), and for the player (which queues player input into the event manager).
I'd guess the bulk of what's going on happens in my own loop, the framelisteners are just used to capture input.
Anyway will soon have some (not great but working) code if you want to pick apart and suggest anything.
Meanwhile we need some ideas, well here's mine:
start off with main menu, blurred tree branches and leaves sway in the background. start game -> trees move aside to reveal your character is a small black cat, the setting is a village / temple as graphically lush as possible (bumpy brickwork, plenty of grass and trees). Basically you'd just wander round, jumping and climbing walls to get to higher places. Throw in some physics objects to bump into as well, maybe even have some collapsing walls. There could be an objective of some food at the top of a building somewhere, and perhaps some enemy birds to kill on the way up.
hmm. I'm sure there must be better ideas for short demos than that ..
You're welcome to use the Python-Ogre.org wiki to host the project, along with the SVN/Sourceforge ..
Also I'd be happy to do the mainmenu -- somethin easy and 'real' while I continue putting out new releases..
And I like the idea of keeping it simple and 'doable' to start with -- we can always add internal rooms for exploration (each showing a different set of special effects) and multiplayer over the internet later on (I intend to add networking to the PythonOgre bundle)
Cheers
Andy
bharling
18-04-2007 10:01:28
Hey thats cool, - do you ever sleep?
.
I've very nearly finished converting my framework into something usable. Hopefully will complete work on that over the weekend and be ready to upload it early next week.
willism
18-04-2007 16:23:20
Well, shall we move this discussion to the python-ogre wiki then? I think that the next step is to better define the goals of the demo, which I think would be easier to do on a wiki, instead of the forum.
Srekel
18-04-2007 18:29:20
Sounds cool. Not sure if I can help with anything (don't really have the time to code on anything besides what I'm already working on), except for trying to help out if you have any ideas about how to put it together and stuff like that.
Though imo, wikis are not meant for discussions. Keep the discussion here, and update the wiki with the conclusions.
bharling
18-04-2007 22:35:44
Cool, the more the merrier!
tbh, I'm hoping the major workload for this is going to be in the areas of models and materials, so if you fancy contributing in that area then please do.
A quick progress update on the preparations :
I've finished a very basic framework, with most of the features I mentioned earlier, which at least runs without error. I'll put together some basic sample content for that and upload it as soon as i can.
I have created a branch to include physics, as it requires a different approach to what I had been using, you'll be able to see why in the source. This framework will hopefully include an automatic way to make walking characters, from
this tutorial , however realised in Newton instead of ODE (dont ask me why).
I've integrated some of this technique already, but need to do some serious testing to see if it actually works.
ergo ideas: What we have so far is good, but of course I'm totally open to suggestions. If the walking character model works as I hope it will, then we should be on course for some interactive characters at least.
@Andy: thanks for the offer, if you have time, please set us up a wiki page, and I'll put stuff there as soon as.
bharling
19-04-2007 09:08:04
Awsome!
Right, guess I better bloody post something there then!
might wait until i have some code to post before begining to edit it.
drummingpariah
19-04-2007 22:40:12
Well, I'm excited enough about this that I just created an account on the forums, just to say that I'll help in any way possible. I'm setting up my new Blender workstation right now, so it'll be a week or so before I can start making any content (which is realistically the only place I'm useful) but if there are some good python exercises that I can actually help with, I'd be more than happy. I'm using python-ogre as an excuse to push on and really learn python. Someone needs to take charge of this project though and define exactly what we want to make, and how we'll do this (define releases and an approximate timeframe). I'm looking forward to it!
willism
20-04-2007 00:48:03
Welcome, drummingpariah! I'm actually glad to hear that we're attracting the attention of more than just people who write code. Even if you don't learn much python, any blender work will be appreciated. My contributions will be mainly code, maybe some textures, and possible a little background music, but I'm a lousy 3D artist.
Like I said before, I think we need to refine our goals and ideas. What do people want to see? Which ideas do people like? Naturally, I have some bias toward my own ideas, as shown in previous posts here
Here's a brain-dump of things that I've thought of in the last couple of days, feel free to disagree on anything:
Should agree on a unit of measurement, such that we don't have to scale everybody's models to fit? I propose 1 unit = 1 meter.
Do we need a menu and user interaction? I'm thinking that we could just have the demo start up and consist of the camera panning and moving around (in dramatic ways of course) to show different parts of the environment that we create.
Should we agree on a theme, so that people can start working on art? I'd like it deliberately whimsical and surreal, rather than trying to be photo-realistic. E.g. fairly high saturation on the colors, maybe some things could have exaggerated shapes and sizes, etc. On the other hand, I'd like to see some continuity, like if we want to make a partical water fountain, put it in the town square, not in a dining room
Also, I would rather not see any killing or gore
bharling
20-04-2007 01:08:18
Sounds good !
Yep, we definitely need to decide on a set of goals. Heres my general suggestions.
Main Project Goals
1. Create something which is great to look at and freely available (source included).
2. Demonstrate how python speeds up the development process
3. Create an alternative and feature-rich demo framework
4. Comment code well, make techniques clear
5. If possible, include physics interactivity
ergo measurements: Yes I agree, 1 unit should equal 1m. However, its difficult to get it right when exporting from blender, we might need a sample blender scene to set the scaling in stone. Also for weights, 1 physics unit = 1 kilogram.
I'm actually quite keen on doing some sort of menu. Mainly again because we can demonstrate a simple approach to doing it with only overlays. I'm only talking about options for 'Start Game'and 'Quit', but include a template framework for expanding this. Again this is not a immense task.
Right, how to decide the theme? We could have a run of ideas from everyone, then do a poll, but I fear it may descend into endless threads, and I'd rather all involved were in agreement. Personally, I'm for a 'small town, set in nice landscape, with people milling around'-type affair. Also yes, no bloodshed etc.
bharling
23-04-2007 09:10:07
Update:
The framework would be complete by now, had I not spent a large part of the weekend on trains which were variously delayed in trying to get to london (thankyou south west trains).
However it is very nearly there:
All the mesh and actor management stuff is working now.
Some integration of physics is done (still a few problems here).
I've done a few bits of sample content and integrated it into a very simple demo.
Still To Do:
re-write of event system
Some fixes to physics
sort out of folder structure
main menu.
I'll do some of that tonight, and release whatever I have tomorrow, in the hope that the community may be able to help fix the bugs.
bharling
23-04-2007 22:10:19
Ok, for what its worth, you can download my attempt at a techdemo framework from here:
http://www.zerofilter.com/tech_demo_physics.zip
Things that Dinnae werk yet, man:
Event system - needs a re-write
main menu - didn't get around to even starting this yet
physics - working - ish, still plenty to do here, but a working framework in place. Code in place for walking actors, and collision tree generation / saving (tree loading not working yet).
oh yeah, sound as well ....
Things that werk:
Standalone application
Spawn interface
Easy character creation
Easily sub-classable actor template
Scene Loading
Simple framelistener
Level config loading
Data Manager class
Managed resource loading
It doesn't sound very interesting when put like that, but please check out the source, there is a lot lurking in there, and I can say that I have put quite a lot of effort into it already.
If it doesn't work, or if you have any questions or improvements please post here.
As mentioned, this is far from complete, but feel free to delve into whatever you want.
In its current form, consider this code as freeware. When it reaches a good enough standard, it will become GPL or similar.
willism
24-04-2007 16:06:37
Hi,
I just downloaded the project and got it running. I already have some ideas about what I want to contribute. Should we get it up on an SVN server so that everybody can start working together on it?
I almost fell on the floor laughing when I watched your Rasta man fall out of the sky and start bumbling around on the ground
. One of the first things I did was edit the sample scene, adding more Rasta men, they all looked like they were struggling to get up on their feet. Then one of them fell off the edge of the world. It looked like an unpleasant experience.
bharling
24-04-2007 18:39:31
Lol!
glad u got a laugh out of it!
well, as I said, there still be a *few* bugs .... (or many)...
I'm going to have a look at the walking mechanism this evening if I dont fall asleep..
How are you finding it to work with?
TBH, I dont think its in a state that I would call ready to put on SVN yet, although the main behind the scenes stuff is in place. Maybe if I can get more improvements done tonight I will see about setting up SVN tomorrow. For now, if u have any patches, please just post the code here, and I will paste it in manually.
Game_Ender
24-04-2007 21:15:34
Well it currently crashes on my Linux setup while my own project runs just fine (haven't run any demos yet). I will recompile the latest PythonOgre SVN and give it another try.
Idea:
You should completely remove the need for the plugins.cfg, resources.cfg, and ogre.cfg. I have done so in my application and it just makes things easier to work with. You can roll those into your own game wide config system.
bharling
24-04-2007 22:31:56
I think I see what you mean. So that method would give you access to all setup parameters within your app, plus you can connect them to a gui. I guess you are using resource listeners, or do you have another method?
its a good idea, but maybe beyond the scope of a simple demo. The closest I've got is trying to stagger some of the resource loading through having scripts for levels. If you fancy looking over the resource stuff in my code I'd be very grateful !, as I'm pretty sure it ain't great...
Game_Ender
24-04-2007 23:04:57
Its nothing that complicated at all. First you create root with no arguments:self.root = Ogre.Root("");
Then you load the plugins explicitly:
extension = '.so'
if 'Windows' == platform.system():
extension = '.dll'
# Loop over list of desired plugins
for plugin in config['plugins']:
plugin_name = plugin + extension
self.logger.info('\tSearching for: %s' % plugin_name)
found = False
# Check to see if plugin exists anywhere along the list of possible paths
for dir in search_path:
plugin_path = os.path.join(dir, plugin_name)
# If found, load it
if os.path.exists(plugin_path):
self.root.loadPlugin(plugin_path)
found = True
# Fail if we can't load a plugin
if not found:
raise GraphicsError('Could not load plugin: %s' % plugin_name)
Then you can explicitly load the resources:
rsrcMrg = Ogre.ResourceGroupManager.getSingleton()
for group in config:
group_cfg = config[group];
for type in group_cfg:
for location in group_cfg[type]:
location = os.path.abspath(location)
# This is the key line, you just call this as many times as you
# want to load resources its exactly what parsing the config
# file does
rsrcMrg.addResourceLocation(location, type, group)
Each one of my scenes explicitly calls the function which contains this code so that they have their resources loaded. I am not sure but you might already be doing something like the already.
About getting rid of Ogre.cfg, I will post code for that in a bit, turns out I was using a hack because of a bug in Python-Ogre when I wrote the code. The gist of it is this:# Explicity create/find your render system here (part that was broken)
# Load options into render system
for name, value in config['RenderingOptions']:
renderSystem.setConfigOption(name, value])
# Set main render system
self.root.setRenderSystem(renderSystem)
Note I have not dealt with changing render system setting in game because my app embeds Ogre in wxWidgets (works on Linux too!) and most render system options are pointless there.
bharling
25-04-2007 10:57:40
Aha! I get it (sorry, it usually takes a couple of tries for things to sink in with me!!)
That makes sense, and would make things better for linux compat as well. Would you mind me including a similar routine in the demo?
Game_Ender
25-04-2007 12:22:30
I would not ming you using anything similar to the code I have posted above.
bharling
25-04-2007 13:36:52
So,
does 'addResourceLocation(loc, type, group)' actually cause the resource to be loaded? I thought that just added the location to the internal register.
In the demo, I have split this up a bit, and am loading the resource groups individually when needed with:
ogre.ResourceGroupManager.getSingleton().initialiseResourceGroup(name)
is that the right way to go about it?
I haven't written much to clean up resources yet, so if you have any pointers for doing that I'd be very grateful.
Game_Ender
25-04-2007 15:17:11
I have not gotten to the resource cleanup stage either but yes I do later call initialiseResourceGroup(), but I just don't remember where right now.
willism
25-04-2007 15:41:40
Ok, I've looked over the code and have a couple of suggestions. I am willing to implement these ideas once the project in in SVN, but I thought that I should see what the community thinks first:
* Buried in GameActor.Spawn, There's code that creates an Ogre Entity and puts it in the scene. Let's say I want to create an Actor that is represented by something other than a single Ogre Entity (e.g. a billboardset, a particle emitter, or maybe even a self-contained tree of SceneNodes with multiple things attached to it). Currently, I would have to override the entire Spawn method, which has a lot of other code that I would have to duplicate. Could we break out the part that creates and populates the Actor's scenenode into a different method that would be easier to override?
* In the DataManager, there's actorDict, which is populated with all possible actor that we might want to create. Surely in a dynamic, introspective language like Python, we could create some kind of auto-discovery of Actor classes, such that each time I make a new kind of Actor, I don't have to manually add it to actorDict. (Disclaimer: I'm not quite sure how to do this)
bharling
25-04-2007 15:56:39
All good points,
1. I could break up the spawn method a bit without problems. I think the best way around it would be to expand the actor __init__ method a bit to specify what sort of media makes up the actor, then add a few handlers to Spawn to automatically pick that up. I agree, it would be best not to have to re-define the spawn method at all, as its quite integral to the workings of the datamanager.
2. actorDict changes, I think I know how to do that, I'll have a look this evening and see what can be done. With what I'm thinking of, it would still be a dictionary of actors, but I'll find a way for it to populate itself.
I'm glad ideas are already coming in, nice to see the project gather some momentum!
bharling
25-04-2007 17:24:17
Ok,
I've implemented Game_Ender's plugin loading stuff (read copied and pasted and changed a few bits..), great idea! With a bit of luck, the SVN version may work on linux too.
actorDict is now self populating, you still have to import the actor directories, ie:
from actors.characters import people
but the demo now reads the __dict__ property of 'people' to populate the actor dict. you can add more actors to people. This kind of lends itself to creating many actor classes within a file. basically it works whereby you import a module like people, and the new cacheActors function reads the __dict__ of that module to get populate the actorDict list, for spawning.
def cacheActors(self):
pKeys = people.__dict__.keys()
for k in pKeys:
if '__' not in k:
if not k in ['ogre', 'base_actor']:
actorDict[k] = people.__dict__[k]
else:
break
there is probably a better way to do it, but this kind of does what you said.
will tackle the spawn function in a bit
Game_Ender
25-04-2007 17:44:25
This code is adapted from an older version of the component system used in my application. It uses a special meta class to add each 'component' to the registry when the class is processed. No need for any import trickery (Note this is loosly based on Trac's component system):
class ComponentMeta(type):
"""
The metaclass (the class of class) for the component class. This takes care
of registering each new component.
"""
_registry = {}
def __new__(cls, name, bases, d):
"""
Called when you do a class declaration, ie "class(object): ..." and
this is that classes metaclass. This is called after the class
declartion has been executed.
"""
new_class = None
# We not dealing with the Component base class so register the classe
if name != 'Component':
# Create our new type
new_class = type.__new__(cls, name, bases, d)
# Generated the full package name of the class ie:
# (mypkg.submod.Myclass) and map it to the new class in the
# registry.
full_name = d['__module__'] + '.' + name
ComponentMeta._registry[full_name] = new_class
else:
# Provide the component class access to the component registry
d['_registry'] = ComponentMeta._registry
new_class = type.__new__(cls, name, bases, d)
return new_class
class Component(object):
"""
The base class for all components, each subclass must implement and
interface. If it doesn't, it shouldn't be a component.
"""
__metaclass__ = ComponentMeta
@staticmethod
def get_class(class_name):
return Component._registry[class_name]
@staticmethod
def create(interface, class_name, *args, **kwargs):
"""
Finds and creates objects based on the class name and given
arguments
"""
return Component.get_class(class_name)(*args, **kwargs)
You would then use it like this:
class MyComp(Component):
def __init__(self, name):
self.name = name
# ... lots of code
# The full package name won't be right
my_comp = Component.create_class('somepackage.MyComp', 'Game_Ender')
my_comp.name
# Prints 'Game_Ender'
willism
25-04-2007 18:23:54
To refactor the Actor Spawn method, could we have it call a "populateSceneNode" method (or something similar), that by default creates an entity, but may be overridden to attach other types of media to the scene node?
bharling
25-04-2007 21:27:05
Yeah, I'm wandering about what best to do with the spawn function now.
with added types and more of them, we'll have to account for deleting them when they need to be removed from the game. At the moment, there's already some problem with the shutdown order (which i'm trying to fix:)) so I reckon the whole entity / Node management may need a look at.
In the short-term, a simple way to do it would be to store a dictionary of entities / particle systems that need to be spawned. You could spawn child actors as well with the same instructions. the datamanager then reads this and executes different instructions depending on the type
I guess the values in the dict would have to include
( type, data =[spawn_name/ meshname etc.., offset, parent])
at spawn time, the datamanager re-builds that dictionary with actual objects / bodies / particles etc.
EDIT: Am trying to re-factor things a bit to make sure stuff gets deleted, and actors refrain from storing references to the world, sceneManager etc.
they shouldn't really need to keep pointers to these objects around.
I'm going to take a look at the spawn method at the same time, as it dictates how easy we make deletion and shutdown. I will also see if I can create a base function for spawning varied types of objects.
willism
25-04-2007 21:50:44
I'm not sure if I understand the removal issue completely, but I'm still thinking that each Actor should be responsible for attaching stuff to the SceneNode. Then (if needed) when the Actor is removed, it should also be responsible for removing all of its content from the scene. That way the datamanager doesn't have to handle every possible thing that could be added to the scene, it just creates an Actor and says "Show thyself!" (possibly passing in a SceneNode that the Actor can use?), then later "Remove thyself!"
bharling
25-04-2007 22:14:22
sorry, yes I meant to say expand the actor spawn function, from the datamanager perspective it will remain simply actor.Spawn( ... ), actor.Delete()
EDIT:
Right: If we want to spawn multiple objects in a single spawn command (which of course makes perfect sense), we need to infer some sort of order to the spawning, so that objects are parented correctly, for example a players gun. It would be good to have a very simple interface to set this up, so I've started toying with a tree structure for setting up a spawn list. You would just throw it a list of settings at the actor __init__(), like this:
actorMesh = MediaType('main_player', 'mesh', 'Rastaman.mesh', 'root', (ogre.Vector3(0.0,0.0,0.0), ogre.Quaternion(0,0,0,0)))
gunMesh = MediaType('rasta_uzi', 'actor', 'weapons.rasta_uzi', 'main_player', positionOffset, rotation)
mediaList.append(actorMesh, gunMesh)
the tree would contain automatic deletion methods for all media types, so:
self.mediaTree = MediaTree( mediaList )
create the mediaTree from a list of mediaTypes
self.mediaTree.build( sceneManager )
pass a sceneManager pointer to create the media for this actor.
parentage of nodes / entities is inferred by the tree structure. The tree also contains methods for creating each bit of media.
self.mediaTree.destroy( sceneManager )
remove all semblance of myself and all children from the given sceneManager.
- How does this sound as a plan?
bharling
26-04-2007 09:23:08
Wow!,
in searching for a suitable tree class to hold actor spawn information, I stumbled on this:
http://www.thescripts.com/forum/thread445306.html
'recursive tree in *one* line of code?, why thank you very much..'
I'm integrating something similar into the techdemo at the moment. It will start off with a list of dictionaries, and hopefully perform the steps above.
willism
27-04-2007 00:09:18
Will an actor have easy access to all of it's "Media"? For example, I want to make an actor that has a particle emitter, and in the AI logic I want it to be able to toggle the emitter on/off.
Also, I think that we should just go ahead and put the project up on SVN. I already have some code to contribute (more than I want to post here), and I would like to see how the framework has progressed since you initially posted the zip file.
bharling
27-04-2007 01:36:25
I should be able to make the tree easy to query. Once built (ie: spawned when the actor spawns), you will be able to execute something like 'self.mediaTree.find('Player_Gun')' to return a pointer to the exact Ogre resource you request. That should enable to modify the resource. It's then up to you whether you keep other references to those objects (ie: self.playerGunEmitter = self.mediaTree.find('Player_Gun')), or just query the tree each time you need to use an object.
so, I've written the basic tree, and am currently doing the build methods. It spawns things in the right parent-child order already, which is promising.
Basically this class will be able to handle all the media that make up an actor, making them simpler to create, manipulate and delete (hopefully).
I agree, lets move it on to SVN, however I dont have access to anywhere. Game Ender, maybe u can get a space on the SVN for this? I'll do another upload in the near future anyway.
bharling
27-04-2007 15:09:01
Little update:
the tree class is coming on very well, and should genuinely help with organising media for an actor. Here's an outline of the main methods available so far. This will all be done within an actor class
1. self.tree = mediaTree( list_of_dicts )
The tree creates itself recursively from a list of dictionaries describing different media such as meshes, particles or even other actors.
2. self.tree.build( sceneManager )
Recusively creates all media in the tree, creating internal references to any entities / nodes / particles etc. that are created.
3. self.tree.find( resourceName )
returns a tuple of pointers to the resource requested, and the sceneNode its attached to.
4. self.tree.destroy( sceneManager )
recursively cleans up all the media, calling the appropriate destructor (sceneManager.destroyEntity, .destroyParticleSystem etc.) for each piece of media in the tree. The recursion for this step is reversed, so children are deleted before parents.
Each actor has a mediaTree, the idea being that the tree holds the only references to the actual media (of course, you can get your own references as well if you wish), making it easy to delete. Note the tree does not hold on to a reference to the sceneManager, so a new pointer must be passed to the tree every time it is accessed. Again, this is an attempt to avoid orphaned pointers when cleaning up the actor.
a typical input list may be:
[ {'name': 'playerBody', 'parent':'root', 'rType':'mesh', 'rName':'Rastaman.mesh', 'offset':ogre.Vector3(0,0,0), 'rotation':ogre.Quaternion(0,0,0,0) },
{'name': 'playerGun', 'parent':'playerBody', 'rType':'mesh', 'rName':'gun.mesh', 'offset':ogre.Vector3(-2,2,0), rotation':ogre.Quaternion(0,0,0,0) } ]
hopefully not too complex, and certainly simpler than creating and tracking everything by hand.
bharling
28-04-2007 00:34:51
ok, new sources are available, download from:
http://www.zerofilter.com/tech_demo_physics.zip
until SVN space materializes.
New Stuff:
added Game_Ender's excellent plugin loading business
added very basic dynamic actorDict creation
added mediaTree class to GameActors
modified examples to show how mediaTree works with Spawn.
Modified various internal methods to try and reduce sharing of pointers.
added fish, smoke and my own rubbish skybox
Stuff thats still Oh-So-Wrong:
Physics: walking setup is definitely broke, bodies seemingly not attached
Timing: proper Event dispacher required.
ShutDown: still crashes unfortunately
Object cleanup: improved, but still not right.
Game_Ender
28-04-2007 00:44:53
If you want more work to do I would try to unify the logging system. That is something that is not really done right now. You would do this by first looking up how to override Ogre and CEGUI's default logging policy. Then you could pipe there messages into a system based on python's logging module. This could then filter all messages in a central place and keep a bunch of text that is mostly useless from scrolling by everytime you run the program. This in turns lets you see better your own messages.
At the time I tried this some bugs in Python-Ogre prevented me from doing it properly (I could only shut off console output and piped everything to files). My limited setup still made it easier to debug why everything was cleaning up properly: ie, why am I still holding a reference to this object!
You can also clean up the output by doing your first import of Python-Ogre like this:
import warnings
warnings.simplefilter('ignore', RuntimeWarning)
import ogre.renderer.OGRE as Ogre
import ogre.physics.OgreNewt as OgreNewt
import ogre.io.OIS
warnings.simplefilter('default', RuntimeWarning)
This get rid of the those bothersome "multiple converters registered" messages". Possibly this should be done by Python Ogre itself, but at a more advanced level (ie it makes sure that's all the message mean).
bharling
28-04-2007 09:55:39
Hey yeah sure, I loves more work!
I was actually thinking 'God I need a better logging system for this' as I was trying to get the recursion working in the mediatree system. Your suggestions seem good, and I'll see about implementing a logging class as soon as I can.
On another note, have u tried the latest sources I uploaded last night, and if so do they work on linux?
willism
01-05-2007 18:21:28
...ping...
What do we need to do to get this thing up on SVN?
bharling
02-05-2007 09:13:21
aha!
Yes SVN is needed asap. I had a look, and unfortunately there is no way I can set up SVN on the server I currently use. I will see if I start a project at sourceforge to serve this. Bear with me a bit and I'll see what can be done!
EDIT:
I have submitted this project to sourceforge for approval, hopefully if they like it, we should have some space to host it properly in the very near future.
EDIT AGAIN:
I just noticed the 'community' branch in the PO trac site, would this be a suitable place to host the techdemo? if so I'll cancel my project registration at sourceforge, if someone on the PO team can sort us out some limited access to that branch (I don't presume to suggest I should have access to the PO trunk, I'll leave that to the pro's !
)
I thought a Community branch with full read/write access would be helpful..
However I haven't got the access rights sorted yet so give me another day or so
Cheers
Andy
bharling
03-05-2007 09:00:39
Ace, nice one! I shall await your nod
OK so I can't get it to allow commits unless you use a username/password..
So:
https://svn.python-ogre.org/trunk/Community is available with anonymous read access (like most SVN's)
Write access is available with username=pythonogre, password=pythonogre
Let me know if this works OK for you
Cheers
Andy
bharling
04-05-2007 13:58:32
willism
04-05-2007 15:59:14
Nice! I have to warn you, at my job I've been nicknamed "Captain Refactor", so you may check in code one night only to find it all ripped up and rearranged the next morning
I already have an addition that I think you'll like, hopefully it will be merged into SVN within a day or two. I'll let you know when it's there.
EDIT:
Ok, it's there, the merge wasn't as hard as I thought. Check it out! (Hint: watch the sky)
Yes, it needs a better mesh. This is just a rough draft.
bharling
04-05-2007 20:38:31
'Captain Refactor' - I like it
downloading now..
EDIT:
Boids!
Class!, it never occurred to me that the actor class could be used in such a way, but of course, thats the great thing about a collaborative project I guess!
Would be cool if we can get them to rotate the right direction (I guess that means some work with lovely quaternions though..), I will have a look over the weekend if i get time.
Nice work though, the performance is great, I added a load more in the level config and saw no real drop in framerate, which is rather cool.
I really need to work on stopping the crash on exit, its a real pain in the rear. Is there a debug tool anyone can reccomend which might catch whats going on? (I tried winPdb but have not had much luck with it).
bharling
06-05-2007 16:43:34
I'm trying to merge some changes onto SVN, but am getting an error '405 - Method not allowed'. Anyone know what might be going on? It seems to refer to the media directory.
I'm just uploading a new landscape and skybox, would that be a problem?
willism
07-05-2007 15:56:28
I don't know. Maybe it's having trouble because they're binaries? You could try first removing from SVN the files that you are trying to replace, then putting up the new ones.
Does anybody else have any suggestions?
Game_Ender
07-05-2007 15:58:25
Are you trying to do an SVN commit? or an actual merge?
bharling
08-05-2007 09:48:21
errm, a commit i think
am a bit newb to working with SVN myself....
willism
09-05-2007 00:42:29
More updates... I just committed a few changes, the major one being that the boids now rotate. It needs some clean up, but I believe in committing early and often. Enjoy!
bharling
09-05-2007 09:06:23
awesome
Well, I'm trying to get together on the graphics side at the moment. I'm trying out skyboxes in blender and Terragen2 (suffice to say, the TG2 ones look rather sexy). I'm also working on a new landscape and some foliage and trees etc. I was going to try and be clever and use shaders for the foliage, but I'm now thinking static geometry would do the job just as well. Anyway, if I can't figure out SVN, I'll just download your new features and re-upload with some of the new media I'm doing.
I'm now thinking I need to do a merge, because I've added stuff to load compositors. Forgive my stupidity, but how can I do a merge of the code I have with the version on SVN? I have both normal svn and tortoise installed.
Game_Ender
09-05-2007 12:44:12
You should probably
read the book. But in a nutshell: Check out the current code from SVN. Copy all you files over the current code. Use TortoiseSVN commit and it will should you all the changed and unknown files. Do an "Add" on all the files which you have added while still in the commit window. Type a descriptive commit message and then commit.
bharling
09-05-2007 14:05:21
Thanks dude, I'll try that when I get out of the thrice accursed office. I'll also have a read of the book
EDIT:
Right, finally commited a new version. New land, new skybox, and bloom effect added. a very few code tweaks. Let me know what you think
bharling
11-05-2007 02:30:10
Ok, another update, main news:
added a fog effect when under the water, it looks rather nice on mine
switch between shadow types with 'H'
**Note:
The demo now has the bloom effect switched on by default, you can disable it by deleting the 'COMPOSITOR=..' line in testLevel.cfg.
added a foliage key in the level config, to load another blender xml scene containing foliage for your game. This is loaded after the physics world has been constructed, so you shouldn't bounce off the grass etc.
Next thing to do would be a trees loader, which just adds newton cylinders as collision bodies for the objects.
as always, get it via svn at:
https://svn.python-ogre.org/trunk/Community/TechDemoProject
(hopefully this time i did the merge right..)
you can also get the blend files i made here:
http://www.zerofilter.com/PyOgre/blends.zip
i used
L3DT to do the island, its a rather neat prog.
bharling
18-05-2007 09:21:53
- BUMP -
Just to let everyone know, SVN is now up to date. This inlcudes:
Actor ray queries (for finding physics world / objects)
Dynamic Sunlight (J / L keys = mess with time)
Sea render to texture ( reflects the sun and sky and island)
Numerous material fixes
You will need a relatively up-to-date pc to run this demo, and you'll certainly need a recent graphics card.
The framerate is dropping in some areas now ( when you look at all the trees at once ), so the next step is to begin optimizing. I already have an idea for the foliage to use an octree-type affair to cull foliage and replace it with billboards where required, anyone know of a better way to do this?
I've removed the bloom effect temporarily, as its a bit over the top, and was affecting framerate.
Check it out ..
chriso
19-05-2007 11:39:16
I downloaded the tech demo using TortoiseSVN, this is the error output I get when trying to run:
ImportError: No module named psyco
TechDemoPhysicsApplication.py - line 8
datamanager.py - line 6
people.py - line 3
Any ideas?
Just comment out that block of code as it's not "failing" nicely...
Andy
bharling
19-05-2007 12:41:50
aha, yes duly noted!
yes comment out that code, it doesn't even need to be there really
well, am having a fixing and cleaning up day today, so will add that to the list
chriso
19-05-2007 12:44:23
The first time I tried running this, it was in a folder called 'New Folder' on my desktop. Then I moved the whole folder to:
C:\PythonOgre\demos\techDemo\
When I run the code (with the psyco block commented), it tries to load files from the old location. Is it storing that location somewhere?
File "C:\PythonOgre\demos\techDemo\TechDemoPhysicsApplication.py", line 8, in
from system.datamanager import *
File "C:\Documents and Settings\Christopher\Desktop\New Folder\system\datamanager.py", line 6, in
File "C:\Documents and Settings\Christopher\Desktop\New Folder\system\actors\characters\people.py", line 3, in
ImportError: No module named psyco
Script terminated.
bharling
19-05-2007 13:22:25
erm, not sure about that one. Try deleting all copies, and unziping a fresh copy to c:\pythonOgre\techDemo or another path without spaces, it should not need to reside in the demos folder.
bharling
21-05-2007 12:16:09
UPDATE:
Have finally got around to adding an event system. Its based on a heapq, and uses a generic event class to allow communication between all the elements of the demo (ie: frameListeners can talk to actors and vice-versa). This includes some fixes to actors which should allow an actor to spawn other actors by creating an event which is passed to the datamanager. This brings the actor 'Update' method into play finally, as much of the AI operations and event generation can be handled in there.
Also, I have droppped printing in favour of logging, so you wont get loads of redundant lines of output when you run the demo.
So, I will sort out an example of this behaviour and update the SVN, hopefully tonight.
cheers
bharling
22-05-2007 00:00:39
Right the update is complete, make sure to have a look around the trees after sunset
Theres quite a few updates this time, and despite all the errors you'll see on exit, its probably the most stable release to date.
Actor deletion should now work. If you need to delete an actor from the game, self.Remove() should do the trick to make an actor commit suicide.
The event system seems to work well, but is perhaps not very intuitive, Check out the skymanager and the new boids to see an example of how to setup events.
Performance on my machine seems to vary wildly at the moment, so there is still work to do on the timing mechnisms. I'm getting fps in the range of 15 - 250 fps (P4 2.8GhzHT, ATIX1650,1.5gb), would be good to know how it performs on other systems (that is, if it even runs .. )
As always I welcome any suggestions or contributions
EDIT: For all those svn haters out there, a VERY EARLY binary demo is available here -
PO TechDemo, its 26MB, so please right-click and Save As.. I will probably have to remove it if the bandwidth skyrockets.
MajinBlayze
29-05-2007 14:19:22
Is this project still active?
bharling
29-05-2007 14:39:12
Yep, it sure is!
Have been doing a bit of optimization recently, and trying to resolve some of the shutdown issues (unfortunately it looks like some re-factoring is required to fix this properly).
We're still looking for contributors so please get involved if you'd like to
inneractive
05-06-2007 09:12:13
I think this project is very helpful for new users so thanks for doing this bharling, and thanks to the other contributors as well.
It's interesting that you chose the island scene as your level because I had also planned to do a small island level as a starter project, mostly as an environment art portfolio piece. I'm a digital arts student so my focus will be on the art content rather than game functionality. My pieces will all be focused on using the latest real-time technologies, like normal-mapping and skeletal based animation, which are a few reasons why I chose Ogre over the other engines I have tried (excellent Maya support is another).
As I complete objects for my level, if you find them suitable, I would be willing to donate them to the project. I know I will be "borrowing" heavily from your code to get my level up and running
bharling
05-06-2007 12:53:10
Hey, glad to hear you find it useful.
As I've mentioned, its still got plenty of bugs but am using any spare time I have to try and fix things ( however my spare time seems to rapidly decrease every day at the moment ).
I think everybody does the 'small island' thing when starting in ogre
I think I would like to change the theme a bit now that a basic engine is running.
saladin
08-06-2007 11:14:16
Hey, glad to hear you find it useful.
As I've mentioned, its still got plenty of bugs but am using any spare time I have to try and fix things ( however my spare time seems to rapidly decrease every day at the moment ).
I think everybody does the 'small island' thing when starting in ogre I think I would like to change the theme a bit now that a basic engine is running.
Hi, there. Congrats and thank you on the effort. I just got the svn version. When I run the program the screen seems to turn all white on me. In ogre.log it complaints about some missing .cg files e.g. 'Example_BumpMapping.cg', so I copied a whole bunch of cg shader files over from the python-ogre media folder. But the problem persists.
Shining some light this way would be appreciated while I white-box the code line by line.
inneractive
08-06-2007 22:28:09
I can confirm that behavior on my system as well. The Tech demo has been working fine for me all week until now.
14:26:28: OGRE EXCEPTION(6:FileNotFoundException): Cannot locate resource Example_BumpMapping.cg in resource group Core or any other group. in ResourceGroupManager::openResource at ..\src\OgreResourceGroupManager.cpp (line 603)
saladin
09-06-2007 02:20:32
When I run the program the screen seems to turn all white on me. In ogre.log it complaints about some missing .cg files e.g. 'Example_BumpMapping.cg', so I copied a whole bunch of cg shader files over from the python-ogre media folder. But the problem persists.
.
... it wasn't long before I realized the white screen was actually a loading screen.
'There was a time when Patience ceased to be a virtue. It was long ago.'
bharling
12-06-2007 09:00:48
Yes!
glad you've all experienced the rather obscure loading screen, I assure you things should happen if you give the loading screen 20 seconds or so!
The reason it takes so long is that its re-generating the collision tree for the landscape every time it loads. I have been trying without success to re-load the previous collision tree into the demo on startup, but there seems to be a problem with creating a dataStreamPtr to the collision cache. If anyone knows how to fix this, please go ahead!
Also if you upgrade to Python-Ogre RC2 don't forget to copy across the plugins\* from the new Python-Ogre installation into your techdemo plugins folder (otherwise you will have interesting crashes etc)
Cheers
Andy
bharling
12-06-2007 18:39:45
Hmm, slight problem there
I did just that and the demo now refuses to run. I went back and checked out the SVN version (which was working as far as I know), copied the dll's over, but unfortunately it just bombs out just after the initial level loading, which makes me think its a framelistener thing.
I've tried every way I know to catch the exception, but I get no error message ( i dont have a proper debugger installed tho ), just the windows crash box with a failure in the VC80 dll, or occasionally ogremain.dll
can anyone shed any light?
I had to comment out the setNamedConstant('fBlend"...) lines in the Skymanager and it's framelistener to get things working...
Thought it was my crappy graphics card but perhaps it's a real problem..
Cheers
Andy
bharling
13-06-2007 09:47:00
Thanks Andy, I will try that as soon as I get a chance.
Do I detect that this is in fact a PO bug? (and not my notoriously shoddy coding
)
EDIT: Yes, that did the trick, but also kills the nice sky unfortunately.
So could this be a problem with the sky shader? I don't know much about shader language, so here's the program if anyone can help.
this is all from mikeInside's 'quick and dirty skymanager'
vertex shader:
float4x4 matViewProjection; // view projection matrix
float2 fAnimSpeed; // 2D vector for animation speed
float fTime0_1; // Time from Ogre, range [0.0, 1.0]
float4 fTexScales; // Scaling for both textures, 2 float2's together; see material file comments
struct VS_INPUT
{
float4 Position : POSITION0;
float2 TexCoord : TEXCOORD0;
};
struct VS_OUTPUT
{
float4 Position : POSITION0;
float2 TexCoord0 : TEXCOORD0;
float2 TexCoord1 : TEXCOORD1;
};
VS_OUTPUT vs_main( VS_INPUT Input )
{
VS_OUTPUT Output;
// Get final vertex position
Output.Position = mul( matViewProjection, Input.Position );
// Speed vector multiplied by time gives you current offset
float2 fAnimBonus = float2(fAnimSpeed.x,fAnimSpeed.y)*fTime0_1;
// When scaling texture coordinates, you're basically repeating the texture faster for larger values, so I reversed it
// Just scales the texture coordinates and adds the offset
Output.TexCoord0 = float2(Input.TexCoord.x * 1/fTexScales.x, Input.TexCoord.y * 1/fTexScales.y) + fAnimBonus;
Output.TexCoord1 = float2(Input.TexCoord.x * 1/fTexScales.z, Input.TexCoord.y * 1/fTexScales.w) + fAnimBonus;
return( Output );
}
and the fragment prog
sampler2D Texture0; //First texture sampler
sampler2D Texture1; // Second texture sampler
float fBlend; // Blend factor, float range [0.0, 1.0]
float4 ps_main(float2 TexCoord0 : TEXCOORD0, float2 TexCoord1 : TEXCOORD1) : COLOR0
{
// Get the two colors from the textures
float4 tex0 = tex2D(Texture0, TexCoord0);
float4 tex1 = tex2D(Texture1,TexCoord1);
// Return the linear interpolated value, based on the Blend factor
// i.e. if fBlend is 0.6, it returns 60% tex0, 40% tex1 (think that's right - might be reverse)
return( lerp(tex0, tex1, fBlend) );
}
dermont
27-06-2007 22:13:52
Not really too sure what the exact problem with the Skymanager and setNamedConstant('fBlend"...) is, but from reading other posts I gather that the current shaders need updating to Cg.
Do you have a standalone sample of what the output is supposed to look like?. I'm using the following code:
sceneManager.setSkyDome(True, "SkydomeShaderBlend", 5, 8)
mActiveMaterial = ogre.MaterialManager.getSingleton().getByName("SkydomeShaderBlend")
mActivePass = mActiveMaterial.getTechnique(0).getPass(0)
mActiveFragmentProgram = mActivePass.getFragmentProgram()
mActiveFragmentParameters = mActivePass.getFragmentProgramParameters()
mNightLight = sceneManager.createLight( "nightLight" )
mActiveFragmentParameters.setNamedConstant("fBlend",0.8)
1) Renaming the current shaders to cg and updating the sky.material to, appears to blend the sky appropriately.
fragment_program skydomePS cg
{
source skydomePS1_4.cg
profiles ps_2_0 arbfp1 fp30
entry_point ps_main
}
vertex_program skydomeVS cg
{
source skydomeVS1_1.cg
profiles vs_2_0 arbvp1 vp30
entry_point vs_main
}
2) Updating the sky material, and modifying the shaders to Cg, appears to do the same.
sky.material
fragment_program skydomePS cg
{
source sky_fp.cg
profiles ps_2_0 arbfp1 fp30
entry_point ps_main
}
vertex_program skydomeVS cg
{
source sky_vp.cg
profiles vs_2_0 arbvp1 vp30
entry_point vs_main
}
...
sky_fp.cg
void ps_main( in float2 TexCoord0 : TEXCOORD0,
in float2 TexCoord1 : TEXCOORD1,
out float4 oColour : COLOR0,
uniform sampler2D Texture0 : register(s0),
uniform sampler2D Texture1 : register(s1),
uniform float fBlend)
{
// Get the two colors from the textures
float4 tex0 = tex2D(Texture0, TexCoord0);
float4 tex1 = tex2D(Texture1,TexCoord1);
// Return the linear interpolated value, based on the Blend factor
// i.e. if fBlend is 0.6, it returns 60% tex0, 40% tex1 (think that's right - might be reverse)
oColour = ( lerp(tex0, tex1, fBlend) );
}
sky_vp.cg
void vs_main( in float4 Position : POSITION,
in float2 TexCoord : TEXCOORD0,
out float4 oPosition : POSITION,
out float2 oTexCoord0 : TEXCOORD0,
out float2 oTexCoord1 : TEXCOORD1,
uniform float4x4 matViewProjection,
uniform float2 fAnimSpeed,
uniform float fTime0_1,
uniform float4 fTexScales )
{
// Get final vertex position
oPosition = mul( matViewProjection, Position );
// Speed vector multiplied by time gives you current offset
float2 fAnimBonus = float2(fAnimSpeed.x,fAnimSpeed.y)*fTime0_1;
// When scaling texture coordinates, you're basically repeating the texture faster for larger values, so I reversed it
// Just scales the texture coordinates and adds the offset
oTexCoord0 = float2(TexCoord.x * 1/fTexScales.x, TexCoord.y * 1/fTexScales.y) + fAnimBonus;
oTexCoord1 = float2(TexCoord.x * 1/fTexScales.z, TexCoord.y * 1/fTexScales.w) + fAnimBonus;
}
Since (1) and (2) do the same thing and shaders isn't my strong point there's probably errors in the above or more to the particular problem.
bharling
28-06-2007 09:36:21
Damn, thanks dermont. I tried to do exactly the same thing myself, but my appreciation of the finer points of Cg is awful (although I think my code came out pretty similar to yours, but it just crashed on my system).
I'll test it out when I next get a chance, but if it works, could you update the SVN with your new shader? Once I've tested it, I will bring it to the attention of the original author (only fair i think, as c++ ogre bods will be having exactly the same problem).
Once again, thanks for your help !
bharling
28-06-2007 09:48:04
On a related tip, I've been trying the demo out on other machines with very mixed (and increasingly confusing results).
So far it works on everything apart from my work pc (core2 duo, 2gb ram, nvidia 8500gt), where it just hangs on the loading screen. Odd you may think, but it gets weirder because yesterday it suddenly decided to play ball, once and once only, then refused to run again with identical engine settings. bizarre eh? Even more bizarre, because this was using the rc2 release, which by all accounts should b0rk when supplied with the shaders mentioned above. As far as I could tell, all was running perfectly (in the one time it ran). This has got me stumped
bharling
30-06-2007 14:53:37
Just to say that the SVN has been updated - No new content as such, but various small fixes and improvements (hopefully gaining a few fps). Also shaders are fixed and it should play nice with RC2.
NicoEchaniz
22-09-2007 05:22:28
Hi everybody,
I have downloaded the SVN version of the TechDemo but it doesn't seem to work with PO 1.0 (linux binary).
I get this error when running TechDemoPhysicsApplication.py :
[...]
Finished parsing scripts for resource group testlevel
Mesh: Loading LandPlane.mesh.
Texture: Land_Lightmap_Large.jpg: Loading 1 faces(PF_R8G8B8,2048x2048x1) with 11 hardware generated mipmaps from Image. Internal format is PF_X8R8G8B8,2048x2048x1.
Mesh: Loading primitivemonkey.mesh.
Texture: monkeyLightMap.tga: Loading 1 faces(PF_R8G8B8,256x256x1) with 8 hardware generated mipmaps from Image. Internal format is PF_X8R8G8B8,256x256x1.
Mesh: Loading ShortGrass.mesh.
Texture: grass4_SKIN#32.bmp: Loading 1 faces(PF_A8R8G8B8,512x512x1) with 9 hardware generated mipmaps from Image. Internal format is PF_A8R8G8B8,512x512x1.
Mesh: Loading BendyPalm.mesh.
Texture: palmtree_palmtexture_2.t.bmp: Loading 1 faces(PF_A8R8G8B8,512x512x1) with 9 hardware generated mipmaps from Image. Internal format is PF_A8R8G8B8,512x512x1.
Mesh: Loading KinkyPalm.mesh.
Mesh: Loading BigDarkBush.mesh.
Texture: bush3_IMG_1409.png: Loading 1 faces(PF_A8R8G8B8,512x512x1) with 9 hardware generated mipmaps from Image. Internal format is PF_A8R8G8B8,512x512x1.
Mesh: Loading StraightPalm.mesh.
Texture: nightcloud2.png: Loading 1 faces(PF_R8G8B8,800x800x1) with 9 hardware generated mipmaps from Image. Internal format is PF_X8R8G8B8,800x800x1.
Texture: daycloud.png: Loading 1 faces(PF_R8G8B8,800x800x1) with 9 hardware generated mipmaps from Image. Internal format is PF_X8R8G8B8,800x800x1.
X Error of failed request: BadAccess (attempt to access private resource denied)
Major opcode of failed request: 2 (X_ChangeWindowAttributes)
Serial number of failed request: 7
Current serial number in output stream: 9
Any hints? Should the TechDemo work with PO 1.0?
bharling
24-09-2007 09:50:54
Hi!
Where did you get the svn version from? I couldn't find it anywhere online anymore. I have not done any work on it for a while unfortunately, but I intend to update it to work PO1.0 as soon as I get a chance.
Sadly, its not linux friendly at the moment, (mainly a paths issue I think). Again, thats something I intend to fix when I get a chance.
bharling
27-09-2007 18:18:49
Thanks Andy
Well, on windows I just copied the latest dlls and plugins.cfg into the techdemo plugins folder and it all seems to be much as it was before ( read: 'a bit flaky..but working')
I'll have a go at making it play with linux, but I have no linux box to hand to test it. I've done this before though, so perhaps it will work
Anyways, I'm trying to write different things with PO at the moment, so am not spending enough time cleaning up the demo. Will hopefully make something interesting available soon though.
Andy > I have a wishlist request
What would you say to wrapping the PagedGeometry engine for the next release?
bharling
29-09-2007 17:37:16
Aha! Yes by Jove thats the one!
I've been trying to build it today without much luck. I think it would be fantastic as part of Python-Ogre if at all possible
Srekel
29-09-2007 17:52:20
What is the license for the tech demo?
bharling
29-09-2007 18:58:02
Errm, same as python-ogre i guess
, although I think i may have included LGPL.txt in the folder by mistake. All the code is completely free to use for any purpose, though it needs drastic improvement, so I'd be grateful if anyone posted any fixes back to the project.
The foliage is from a free library of .mdl foliage, i think details are in the zip file, again its a completely liberal license
finally some of the skyboxes are done with terragen2 beta, which
does prevent using them in a commercial project, but the demo does not use a skybox currently, but the simpledirtyskymanager by mikeInside - source available in the showcase forum.
everything else in the project has been directly contributed or taken from ogre or python-ogre and is again free to use for all purposes -- as far as I know.
the main reason i included gpl is the 'no warranty' bit, when you use the techdemo project, you are doing so at your own risk! ( as i said, its a bit flaky in places )
bharling
06-10-2007 16:52:26
I see you've added pagedGeometry Andy!
I think i actually love you
well, i think i shall await version 1.1 and do a major re-working of the old demo around that time. Theres soo much stuff in PO now, it must surely be one of the most complete game creation kits available now