Hi all,
I know this issue has been discussed several times now, but I am still unsure about the current state, so I’d like to ask it again. If I start being bothering, I apologize for that.
I am currently thinking of a way to get some sort of map system into my game. Yesterday I was looking at http://www11.brinkster.com/chapter23/default.htm, which is a Q3 level previewer written in Java, but using Gl4Java. Sadly it does not work correctly on my pc, at least not the demos from nr. 3 onwards. Anyway, I thought it would give me some ideas on how to do things and what to do next.
First let me sum up what I believe to have understood.
If I was planning to have a similar map system inside a jME based game, I would have to do the following:
a) provide some sort of Geometry which reflects the map system. The point here is that in a usual map the map faces can be attached to different textures. IIRC, single geometry objects currently can only be attached to a single texture, which means that I would need to create a
single jME scenegraph node for each map face, attaching the related texture state to it. Which would result in a huge scene graph tree;
b) provide algorithms to implement BSP-aware rendering and collision detection. There would additionally be the need to attach the new physics system to this structure or at least some sort of terrain following in order to let players be attached to the floor even on ramps rather than flying around or slipping through the walls. Because a jME scene graph is a tree too, the BSP information would probably be outside of the scene graph in some parallel object structure, which is then evaluated by these algorithms? Maybe some sort of top level BSPNode, which maintains the faces nodes undeneath it? Here I am completely in the dark;
c) provide a converter class to convert a pk3 file into a .jme file, which can then be loaded and used inside jME.
Now my questions: does anything I have written here make any sense to you? Am I wrong somewhere or everywhere? And, most importantly, is somebody probably currently already working on one of these issues?
Answers would be greatly appreciated, since the outcome will determine, what I will do next. If someone is already solving these problems, I’ll switch over to other areas which I need to look into.
Or, I could offer help in working on these things, although I must admit, that I have to dive into the subject deeper first.
Thanks for any answers.
Greetinx from pre-christmas germany.
Yes, BSP support or something would be great.
c) provide a converter class to convert a pk3 file into a .jme file, which can then be loaded and used inside jME.
I think pk3 files are just renamed zips. Just like jars.
Cep21 is working on bsp support.
"Per" wrote:
I think pk3 files are just renamed zips. Just like jars.
I know, but they contain more interesting things than just a bsp file, like q3 shader files and the textures themselves. So in order to write a complete (more or less at least) converter one would need to look into the pk3 file.
Cep, can you give a small life sign about the state of your work concerning this, please? Can I be of any help?
I sadly havn’t had the time I hoped to invest in BSP and portals. I was hoping that would change during Xmas break. If you wanted to take it that would be fine with me. I can help with any questions.
If you do take over the devilment, I would suggest that you consider putting that map data into the .jme format and then righting a converter. The advantage of this would be that you could use a tool made for jme to improve the map before use. (For example customize the render states).
"Chman" wrote:
I find the book on amazon, you could alwais buy it online :)
But not in the german amazon... I've looked for weeks now. :'(
Anyway, I had a look at the wild magic sources. I'm gonna have a tough time, but I will try to solve it using this (My C++ is a bit rusty after so many years of java). I think I am going to post several of my ideas, questions about things I am unsure of etc. on this forum, so be prepared for some heavy traffic here in the future ;)