Hi.
Just some question about this format.
From what I've read so far about this support is that it can read .BSP files created for QUAKE III games. As far as I know it cannot read files produced for the SOURCE engine.
Right now, what can IRRlicht retrieve from this file format?
This would be really nice, If I could use this format (using the HAMMER editor) and import one of my level directly inside IRRlicht.
The .BSP files created in HAMMER have some precalculated "portaling" that define the "zones" (as specific rooms) in your map design.
I don't know all the capabilities of the current .bsp loader in IRRlicht. If someone as more info about it. It would be great.
Also, someone know about an alternative editor that can produce BSP directly compatible with the current one or a tool to convert from BSP files produced in HAMMER to a format readable by IRRlicht?
BSP format with IRRlicht...
-
christianclavet
- Posts: 1638
- Joined: Mon Apr 30, 2007 3:24 am
- Location: Montreal, CANADA
- Contact:
BSP format with IRRlicht...
Last edited by christianclavet on Mon Dec 14, 2009 12:59 am, edited 2 times in total.
-
Dark_Kilauea
- Posts: 368
- Joined: Tue Aug 21, 2007 1:43 am
- Location: The Middle of Nowhere
Psst. Quake 3 also includes pre-calculated portal information (It's part of the BSP design). No, irrlicht does not load or use any Visibility information, someone will have to write code to load that data, then create a scenenode to preform the necessary culling based of the visibility data.
rogerborg wrote:Every time someone learns to use a debugger, an angel gets their wings.
-
christianclavet
- Posts: 1638
- Joined: Mon Apr 30, 2007 3:24 am
- Location: Montreal, CANADA
- Contact:
So at the moment it's loading only the mesh information?
The BSP seem also to contain the lightmap textures and fake reflection cubesmaps.
Would be useful to have implemented format that would support this.
As for entities, that could be changed for empty nodes. The entity named "func_detail" could converted since the geometry is inside the file.
Anybody interested?
The BSP seem also to contain the lightmap textures and fake reflection cubesmaps.
Would be useful to have implemented format that would support this.
As for entities, that could be changed for empty nodes. The entity named "func_detail" could converted since the geometry is inside the file.
Anybody interested?
-
christianclavet
- Posts: 1638
- Joined: Mon Apr 30, 2007 3:24 am
- Location: Montreal, CANADA
- Contact:
Cool! Nice info to know Hybrid!
So the current capabilities of the BSP loader are:
- Quake 3 BSP type compability
- Support for basic geometry (func_detail support unknown?)
- Can support for embedded textures (for Lightmaps), (fake reflection cubemaps support image support unknown (anyway IRRlicht doesnt support cubemaps reflections for an area)
How are textures references handled? In Hammer it use a custom format...
Anyone know of a converter tool from Hammer/Source to that format?
The cubemap in Source is used the same way as the Skybox with the fixed shader (as EMT_REFLECTION_2_LAYER and EMT_TRANSPARENT_REFLECTION_2_LAYER) but instead of usign the skybox as the global reflection for all, they use a specific cubemap for each region (by the way this is generated by using a RTTCAMERA then saved as a cubemap inside the BSP, we only position an entity in the map where we could like the RTT_CAM to take the pictures). This is very good to fake reflections in indoor environments. As for the IRRlicht method, this is sufficient for outdoor scenes.
I wonder if somebody have done this with IRRlicht (we could assign a cubemap PER node or per GEOMETRY)
EDIT: Wow! Long time not using IRRlicht! I just forgot that we can define the reflection PER material! (As using the fixed pipeline functions). So that can be set per model. Sorry.
Another thing that I found interesting is their 3D skybox. They create some low detail geometry used as a background. Position a RTT_camera in the middle of the little scene. This is then rendered by the RTT Cam and put back in another SKYBOX. The RTT CAM is matching the camera rotation and position (position is scaled to a lower scale). This create incredible backgrounds...
So the current capabilities of the BSP loader are:
- Quake 3 BSP type compability
- Support for basic geometry (func_detail support unknown?)
- Can support for embedded textures (for Lightmaps), (fake reflection cubemaps support image support unknown (anyway IRRlicht doesnt support cubemaps reflections for an area)
How are textures references handled? In Hammer it use a custom format...
Anyone know of a converter tool from Hammer/Source to that format?
The cubemap in Source is used the same way as the Skybox with the fixed shader (as EMT_REFLECTION_2_LAYER and EMT_TRANSPARENT_REFLECTION_2_LAYER) but instead of usign the skybox as the global reflection for all, they use a specific cubemap for each region (by the way this is generated by using a RTTCAMERA then saved as a cubemap inside the BSP, we only position an entity in the map where we could like the RTT_CAM to take the pictures). This is very good to fake reflections in indoor environments. As for the IRRlicht method, this is sufficient for outdoor scenes.
I wonder if somebody have done this with IRRlicht (we could assign a cubemap PER node or per GEOMETRY)
EDIT: Wow! Long time not using IRRlicht! I just forgot that we can define the reflection PER material! (As using the fixed pipeline functions). So that can be set per model. Sorry.
Another thing that I found interesting is their 3D skybox. They create some low detail geometry used as a background. Position a RTT_camera in the middle of the little scene. This is then rendered by the RTT Cam and put back in another SKYBOX. The RTT CAM is matching the camera rotation and position (position is scaled to a lower scale). This create incredible backgrounds...
Last edited by christianclavet on Thu Nov 06, 2008 3:31 pm, edited 1 time in total.
-
Dark_Kilauea
- Posts: 368
- Joined: Tue Aug 21, 2007 1:43 am
- Location: The Middle of Nowhere
Source's BSP format, while using the same basic principals as the Quake 1 format (which Quake 2 and 3 developed on), is very different in terms of internal structure.
Entities starting in func_ is the basic naming convention for entities that have a mesh attached (since Quake 1). Irrlicht would have to have an idea of what the entity was in order to load these correctly. Also, in Quake 3, textures are just simple jpg or tga files, valve uses a custom format, which uses a vmt file to define the shader used to render that texture.
There are more specific documents on the internet that describe the various formats in far more detail and could be used to enhance the loader, however, this probably goes beyond what irrlicht wants to support in order to stay just a 3D rendering engine.
Entities starting in func_ is the basic naming convention for entities that have a mesh attached (since Quake 1). Irrlicht would have to have an idea of what the entity was in order to load these correctly. Also, in Quake 3, textures are just simple jpg or tga files, valve uses a custom format, which uses a vmt file to define the shader used to render that texture.
There are more specific documents on the internet that describe the various formats in far more detail and could be used to enhance the loader, however, this probably goes beyond what irrlicht wants to support in order to stay just a 3D rendering engine.
rogerborg wrote:Every time someone learns to use a debugger, an angel gets their wings.
-
christianclavet
- Posts: 1638
- Joined: Mon Apr 30, 2007 3:24 am
- Location: Montreal, CANADA
- Contact:
There is 2 "func_*" that would be really nice to have supported someday:
The term I'm using there come from SourceSDK, they should have about the same in Q3 (Hope)
- Func_detail (its exactly the same geometry as the BSP, exept that this groups is not processed by the VIS process as this is only to create details in the room (molding, pipes, staircases, pillars, etc.)
- Func_brush (same as func details, but it as a visibility flag and collision flag to make it solid/invisible) also it can be named and triggered by entities in the map. Used a lot for moving platforms elements, recessing walls, etc.
- Func_illusionnary (same as func_brush, but this one as NO collision whatsoever)
For the textures, we could put JPG or define that in the map loader. Right now the Q3 maps load with their textures..
The term I'm using there come from SourceSDK, they should have about the same in Q3 (Hope)
- Func_detail (its exactly the same geometry as the BSP, exept that this groups is not processed by the VIS process as this is only to create details in the room (molding, pipes, staircases, pillars, etc.)
- Func_brush (same as func details, but it as a visibility flag and collision flag to make it solid/invisible) also it can be named and triggered by entities in the map. Used a lot for moving platforms elements, recessing walls, etc.
- Func_illusionnary (same as func_brush, but this one as NO collision whatsoever)
For the textures, we could put JPG or define that in the map loader. Right now the Q3 maps load with their textures..
May I ask whether visibility will be eventually added?
I understand you don't want to evolve into a bsp-focussed game engine instead of just a generic 3d rendering engine, but visibility is something that seems quite hard to be done by someone not having extensive knowledge of the bsp format and the necessary maths - and at the same time, without visibility, the whole bsp loading and displaying feature in Irrlicht is more or less useless on slower machines (how would you ever want to use it for larger levels at decent speed?).
I understand you don't want to evolve into a bsp-focussed game engine instead of just a generic 3d rendering engine, but visibility is something that seems quite hard to be done by someone not having extensive knowledge of the bsp format and the necessary maths - and at the same time, without visibility, the whole bsp loading and displaying feature in Irrlicht is more or less useless on slower machines (how would you ever want to use it for larger levels at decent speed?).