dotScene disadvantages?
-
- Gremlin
- Posts: 164
- Joined: Sun Apr 14, 2013 8:51 pm
- x 10
dotScene disadvantages?
Just a question, i was thinking to replace the "obsolete" (i think) dotScene XML format with other more lightweight as JSON and BSON, but before put efforts i need which drawbacks has the current dotScene implementation (including the old TinyXML and the Ogitor's RapidXML dotscene loader)
-
- Goblin
- Posts: 287
- Joined: Mon Dec 08, 2008 4:49 pm
- x 10
Re: dotScene disadvantages?
I still use dotscene, and it works fine for me. (I use it to define the static part of a scene). I am not sure why you are considering another format. Is that memory? loading time?
Still, some ideas from me for if you will do something like that:
0) dotscene is really constructed based on how Ogre 1.x handles scenes. If you are going to define something new, please look into Ogre 2.0 development. there are going to be some significant changes in the scene handling.
1) consider YAML. It is the most human-readable format I've encountered, and still very compact. I haven' t ever used it though, because our company's config files are all either xml or ini, but to me YAML seems a very good choice. However, something in favor of JSON and xml is that they are better supported (e.g. in Python they are in the standard library, YAML requires an extra lib)
2) as I guess you are planning on creating a loader for the format, you might want to look into possibilities to extend the loader. For example, in our company I've modified the dotscene loader to be able to place Text objects. I could imagine others would like to be able to place spawn points, triggers, etc. If you would have an abstract base class for Factory classes, you could make this much easier. If someone needs spawn-points, he could write a Factory class, register it with the new dotscene loader as loader for "spawn_point" elements, and then every time the loader encounters a spawn_point, it will call that loader.
3) dotscene was linked to an Ogre scene editor. I don't use that editor, but I could imagine others do. What is your plan? exporter from blender? custom editor? or just specify the format and users need to create their own?
4) I think dotscene misses some of the new terrain features. I could imagine for some games you would also want to be able to link to other scene files (for different areas of the map, or interior/exterior switching), but as that has a lot to do with how you
Still, some ideas from me for if you will do something like that:
0) dotscene is really constructed based on how Ogre 1.x handles scenes. If you are going to define something new, please look into Ogre 2.0 development. there are going to be some significant changes in the scene handling.
1) consider YAML. It is the most human-readable format I've encountered, and still very compact. I haven' t ever used it though, because our company's config files are all either xml or ini, but to me YAML seems a very good choice. However, something in favor of JSON and xml is that they are better supported (e.g. in Python they are in the standard library, YAML requires an extra lib)
2) as I guess you are planning on creating a loader for the format, you might want to look into possibilities to extend the loader. For example, in our company I've modified the dotscene loader to be able to place Text objects. I could imagine others would like to be able to place spawn points, triggers, etc. If you would have an abstract base class for Factory classes, you could make this much easier. If someone needs spawn-points, he could write a Factory class, register it with the new dotscene loader as loader for "spawn_point" elements, and then every time the loader encounters a spawn_point, it will call that loader.
3) dotscene was linked to an Ogre scene editor. I don't use that editor, but I could imagine others do. What is your plan? exporter from blender? custom editor? or just specify the format and users need to create their own?
4) I think dotscene misses some of the new terrain features. I could imagine for some games you would also want to be able to link to other scene files (for different areas of the map, or interior/exterior switching), but as that has a lot to do with how you
- Kojack
- OGRE Moderator
- Posts: 7157
- Joined: Sun Jan 25, 2004 7:35 am
- Location: Brisbane, Australia
- x 534
Re: dotScene disadvantages?
Dotscene has been around for a LONG time, since at least 2003. There weren't really any editors (that I can remember) back then, certainly not any that are still in use.jonim8or wrote:3) dotscene was linked to an Ogre scene editor. I don't use that editor, but I could imagine others do. What is your plan? exporter from blender? custom editor? or just specify the format and users need to create their own?
But most ogre exporters and editors support it to some degree (there's variations in support, I think usually the OgreMax loader code is the most feature complete). Although the Ofusion max exporter created it's own OSM competing format.
I haven't tried the new terrain component with dotscene. It wouldn't surprise me if most of the older loader code didn't have all of the terrain's features exposed.jonim8or wrote:4) I think dotscene misses some of the new terrain features. I could imagine for some games you would also want to be able to link to other scene files (for different areas of the map, or interior/exterior switching), but as that has a lot to do with how you
-
- Gremlin
- Posts: 164
- Joined: Sun Apr 14, 2013 8:51 pm
- x 10
Re: dotScene disadvantages?
Thanks you for your replies.
@jonim8or:
1)About YAML, i was considered that before using the yamlcpp library, but i find more performance-extensive JSON/BSON C++ libraries and even for production use (gason, rapidjson), JSON is for editing purposes ,and BSON for deploying final scenes, ready to use in applications (games, simulations, etc).
2) Also was thinking about that, of Factory for triggers, spawns, etc.because i developing an logic node editor for levels in my game and i need the factories, usually factory was called as "Actors" brandaname in my engine.
3) Custom editor for my engine (Workbench is called), but open-format, extensible and easy to use.
4) I see also that problem with an older version of dotScene (but ported) using the Stable version of Ogre 1.9, and also i was testing Level Streaming techniques in OGRE to avoid at least loading screens or screen freezes while loads the other part of the level, and linking scenes will be helpful?, i use some meshes as indoors.
@jonim8or:
1)About YAML, i was considered that before using the yamlcpp library, but i find more performance-extensive JSON/BSON C++ libraries and even for production use (gason, rapidjson), JSON is for editing purposes ,and BSON for deploying final scenes, ready to use in applications (games, simulations, etc).
2) Also was thinking about that, of Factory for triggers, spawns, etc.because i developing an logic node editor for levels in my game and i need the factories, usually factory was called as "Actors" brandaname in my engine.
3) Custom editor for my engine (Workbench is called), but open-format, extensible and easy to use.
4) I see also that problem with an older version of dotScene (but ported) using the Stable version of Ogre 1.9, and also i was testing Level Streaming techniques in OGRE to avoid at least loading screens or screen freezes while loads the other part of the level, and linking scenes will be helpful?, i use some meshes as indoors.
-
- Gremlin
- Posts: 164
- Joined: Sun Apr 14, 2013 8:51 pm
- x 10
Re: dotScene disadvantages?
Oops i forget:
Where i can find the new Ogre2.x Scene Manager design information?, is better now than later, i don't want my code will be a mess with lots of #if, #else, #endif preprocessor macros and compatibility issues around scene formats or switching engine versions, (also i read Ogre 1.x has performance issues, then when 2.x will be released, we moving to 2.x to get latest features in my game, nowtodays supposed "gamers" wants eyeburning sunlights and fancy lens-flare)
Where i can find the new Ogre2.x Scene Manager design information?, is better now than later, i don't want my code will be a mess with lots of #if, #else, #endif preprocessor macros and compatibility issues around scene formats or switching engine versions, (also i read Ogre 1.x has performance issues, then when 2.x will be released, we moving to 2.x to get latest features in my game, nowtodays supposed "gamers" wants eyeburning sunlights and fancy lens-flare)
-
- Greenskin
- Posts: 114
- Joined: Mon Oct 14, 2013 1:41 am
- Location: Chile
- x 3
Re: dotScene disadvantages?
I'm pretty sure the problem with the current dotScene format is not the loader, but the exporters, if you change the format, who is going to write new exporters for 3ds Max, Blender, and so on... that create .scene/.mesh/.skeleton files??
Indeed, if you change the dotScene format, you'll become an island until bridges are built from mainland...
Indeed, if you change the dotScene format, you'll become an island until bridges are built from mainland...
Integrated: Ogre3D + dotScene (Blender loader) + MyGUI (UI) + RakNet (Client/Server) + Leap Motion (The future is here!) + StereoManager (3D Anaglyph red-cyan)
WIP: StereoManager (Real 3D) + CCS (Camera Control System) + Sound, experimenting with Android.
WIP: StereoManager (Real 3D) + CCS (Camera Control System) + Sound, experimenting with Android.
- Zonder
- Ogre Magi
- Posts: 1168
- Joined: Mon Aug 04, 2008 7:51 pm
- Location: Manchester - England
- x 73
Re: dotScene disadvantages?
I think JSON is a more natural format for OGRE as everything else is in a similar style. And having the ability to use BSON is also not a bad idea of course it should just be another format that it can support.
Maybe you should check out the new resource system redesign as well.
Maybe you should check out the new resource system redesign as well.
There are 10 types of people in the world: Those who understand binary, and those who don't...
- Zonder
- Ogre Magi
- Posts: 1168
- Joined: Mon Aug 04, 2008 7:51 pm
- Location: Manchester - England
- x 73
Re: dotScene disadvantages?
I was thinking on this a bit more there is no reason the format has to differ too much from the original. I just put the example XML from the wiki through an online converter
Code: Select all
<scene formatVersion="">
<nodes>
<node name="Robot" id="3">
<position x="10.0" y="5" z="10.5" />
<scale x="1" y="1" z="1" />
<entity name="Robot" meshFile="robot.mesh" static="false" />
</node>
<node name="Omni01" id="5">
<position x="-23" y="49" z="18" />
<rotation qx="0" qy="0" qz="0" qw="1" />
<scale x="1" y="1" z="1" />
<light name="Omni01" type="point" intensity="0.01" contrast="0">
<colourDiffuse r="0.4" g="0.4" b="0.5" />
<colourSpecular r="0.5" g="0.5" b="0.5" />
</light>
</node>
</nodes>
</scene>
Code: Select all
{
"scene": {
"nodes": {
"node": [
{
"-name": "Robot",
"-id": "3",
"position": {
"-x": "10.0",
"-y": "5",
"-z": "10.5"
},
"scale": {
"-x": "1",
"-y": "1",
"-z": "1"
},
"entity": {
"-name": "Robot",
"-meshFile": "robot.mesh",
"-static": "false"
}
},
{
"-name": "Omni01",
"-id": "5",
"position": {
"-x": "-23",
"-y": "49",
"-z": "18"
},
"rotation": {
"-qx": "0",
"-qy": "0",
"-qz": "0",
"-qw": "1"
},
"scale": {
"-x": "1",
"-y": "1",
"-z": "1"
},
"light": {
"-name": "Omni01",
"-type": "point",
"-intensity": "0.01",
"-contrast": "0",
"colourDiffuse": {
"-r": "0.4",
"-g": "0.4",
"-b": "0.5"
},
"colourSpecular": {
"-r": "0.5",
"-g": "0.5",
"-b": "0.5"
}
}
}
]
}
}
}
There are 10 types of people in the world: Those who understand binary, and those who don't...
- Kojack
- OGRE Moderator
- Posts: 7157
- Joined: Sun Jan 25, 2004 7:35 am
- Location: Brisbane, Australia
- x 534
Re: dotScene disadvantages?
Here's the same scene file implemented in Lua.
Well, one way of implementing it in Lua, there's many different ways.
Code: Select all
add{
node{
name="Robot",
id=3,
position={10.0, 5, 10.5},
scale={1, 1, 1},
entity{
name="Robot",
meshFile="robot.mesh",
static=false
}
},
node{
name="Omni01",
id=5,
position={-23, 49, 18},
rotation={0, 0, 0, 1},
scale={1, 1, 1},
light{
name="Omni1",
type="point",
colourDiffuse={0.4, 0.4, 0.5},
colourSpecular={0.5, 0.5, 0.5}
}
}
}
- Klaim
- Old One
- Posts: 2565
- Joined: Sun Sep 11, 2005 1:04 am
- Location: Paris, France
- x 56
- Contact:
Re: dotScene disadvantages?
Note that in some case you do want xml, in particular when in tools you need to check file coherency by exploiting the type system (which is not present in JSON).
But as soon as you have xml, it's easy to generate JSON and YAML formats.
But as soon as you have xml, it's easy to generate JSON and YAML formats.
-
- Gremlin
- Posts: 164
- Joined: Sun Apr 14, 2013 8:51 pm
- x 10
Re: dotScene disadvantages?
Well, i appreciate that, i'm aknowledged about the dotScene format can be implemented with any , but my team decided use JSON/BSON, and why?, because their binary couterpart BSON, this a standarized-like binary format, giving a considerable performance boost.
-
- Gremlin
- Posts: 164
- Joined: Sun Apr 14, 2013 8:51 pm
- x 10
Re: dotScene disadvantages?
I'm working in my own editor, im fine thanks , i don't need exporters if was applied for a scene, i use the standard ones of OGRE for meshes and .skeleton files, i can live with that, the original reason of this topic i was researching disadvantages of the dotScene format to create my own, but editor-mine dependient (but easy to export, since their previous posters says exists JSON to XML exporters, i don't think was a problem).RigoCL wrote:I'm pretty sure the problem with the current dotScene format is not the loader, but the exporters, if you change the format, who is going to write new exporters for 3ds Max, Blender, and so on... that create .scene/.mesh/.skeleton files??
Indeed, if you change the dotScene format, you'll become an island until bridges are built from mainland...
-
- OGRE Expert User
- Posts: 1920
- Joined: Sun Feb 19, 2012 9:24 pm
- Location: Russia
- x 201
Re: dotScene disadvantages?
Nice tries, but you can't beat YAML at that:
Code: Select all
scene:
nodes:
node:
name: Robot
id: 3
position: [ 10, 5, 10.5 ]
scale: 1
entity: { name: Robot, meshFile: robot.mesh, static: false }
node:
name: Omni01
id: 5
position: [ -23, 49, 18 ]
rotation: [ 0, 0, 0, 1 ]
scale: 1
light: { name: Omni01, type: point, intensity: 0.01, contrast: 0, colourDiffuse: [ 0.4, 0.4, 0.5 ], colourSpecular: 0.5 }