Premierement un grand bravo pour ton travail sur ce projet. Je suis deja fan ;)
I'm very curious about sunFlow and i would like to ask some basic questions about the file format.
Optionnaly i would like to wrote a parser but i need some informations. Where can i found them ?
Is the file format definitive or a xml file format could be implemented ?
is there also any chance to access the javadoc inline ?
Cya !
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The file format is not really documented at the moment. The best is probably to look at the example files and the SCParser class.
The file format as it is now is getting unmaintainable. This is why the API has evolved to a parameter/object system. After v0.07.1 comes out I will start working on a new file format that mirrors the API more closely which will be both simpler to read, parse and understand.
An XML format would be totally possible. In fact, since Sunflow supports custom parsers, it could co-exist with any of the other supported file formats.
I will post the javadocs as part of my documentation effort after v0.07.1 is released.
Chris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-01-22
I think a nice well structured XML format would be very nice and handy. I don't know if it would be quicker to parse large files or if it would be even easier to maintain changes for you if you use an (standard) XML parser. But perhaps exchange between other renderer (like indigo) could be possible if the file format is equal (or at least easy convertible).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I will consider this. Of course XML isn't appropriate for large amounts of geometric data for speed reasons, but for settings and shader assignments it would be fine.
Interoperability with renderers like Indigo would be best achieved by writing a custom Indigo scene file parser inside Sunflow. The designs of the two renderers are different enough that it would be hard to try and unify their input formats.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Interesting. But if I read correctly this parser still keeps the whole xml file in memory (albeit in optimized form). This is still too much overhead for large scenes. Even with a SAX parser (tricky to write), XML is an ascii file format so large amounts of numbers (read: face/vertex data for meshes) take up way more space than they should.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm very interested about this point maybe like yafray offer the scene description in an xml format and the geometrics data in another one could be an advantage. All tools offers .obj export and xml scene description let us easily write tools around sunFlow. It's great that we can swap parsers !
Let us knows about your point of view and the choice u will do for the file format for SunFlow !
Robbie
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yep. This is already possible actually. The include statement in the .sc files or the parse(String filename) command in the API will invoke a custom parser for that file format. This means you can mix input formats freely. For example, if someone wrote a Yafray XML parser, you could have a .sc file that looked like:
and so on ... Basically you would bring in the geometry/basic shaders and then tweak it further with the sunflow syntax. The new file format I am planning will have the notion of updating existing objects (which is already possible via the API). So you can declare an mesh once (via a parser for your favorite file format), then attach sunflow specific attributes to it _later_ via an update command. Likewise the update can be done programmatically so it could be done inside a GUI. Pretty much anything can be changed and Sunflow will only rebuild what is necessary to support that change, not the whole scene.
Take a look at the SunflowAPI and the Parser interface to see how this works - its really quite simple. If anyone wants to write a parser for their favorite file format let me know, I will gladly include it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all !
Premierement un grand bravo pour ton travail sur ce projet. Je suis deja fan ;)
I'm very curious about sunFlow and i would like to ask some basic questions about the file format.
Optionnaly i would like to wrote a parser but i need some informations. Where can i found them ?
Is the file format definitive or a xml file format could be implemented ?
is there also any chance to access the javadoc inline ?
Cya !
Merci!
The file format is not really documented at the moment. The best is probably to look at the example files and the SCParser class.
The file format as it is now is getting unmaintainable. This is why the API has evolved to a parameter/object system. After v0.07.1 comes out I will start working on a new file format that mirrors the API more closely which will be both simpler to read, parse and understand.
An XML format would be totally possible. In fact, since Sunflow supports custom parsers, it could co-exist with any of the other supported file formats.
I will post the javadocs as part of my documentation effort after v0.07.1 is released.
Chris
I think a nice well structured XML format would be very nice and handy. I don't know if it would be quicker to parse large files or if it would be even easier to maintain changes for you if you use an (standard) XML parser. But perhaps exchange between other renderer (like indigo) could be possible if the file format is equal (or at least easy convertible).
I will consider this. Of course XML isn't appropriate for large amounts of geometric data for speed reasons, but for settings and shader assignments it would be fine.
Interoperability with renderers like Indigo would be best achieved by writing a custom Indigo scene file parser inside Sunflow. The designs of the two renderers are different enough that it would be hard to try and unify their input formats.
"Of course XML isn't appropriate for large amounts of geometric data"
It was the case using DOM parser like JDOM but
http://vtd-xml.sourceforge.net/
really speed up performance for huge xml volume ! and i'm sure it will be concrete solution for sunflow.
more :
http://www.javaworld.com/javaworld/jw-03-2006/jw-0327-simplify.html
http://www.devx.com/xml/Article/22219/0/page/1
some bench :
http://www.javaworld.com/javaworld/jw-03-2006/jw-0327-simplify.html?page=4
Interesting. But if I read correctly this parser still keeps the whole xml file in memory (albeit in optimized form). This is still too much overhead for large scenes. Even with a SAX parser (tricky to write), XML is an ascii file format so large amounts of numbers (read: face/vertex data for meshes) take up way more space than they should.
I'm very interested about this point maybe like yafray offer the scene description in an xml format and the geometrics data in another one could be an advantage. All tools offers .obj export and xml scene description let us easily write tools around sunFlow. It's great that we can swap parsers !
Let us knows about your point of view and the choice u will do for the file format for SunFlow !
Robbie
Yep. This is already possible actually. The include statement in the .sc files or the parse(String filename) command in the API will invoke a custom parser for that file format. This means you can mix input formats freely. For example, if someone wrote a Yafray XML parser, you could have a .sc file that looked like:
>>>
include yafray_scene.xml
image {
resolution 640 480
aa 0 2
filter mitchell
}
....
<<<<
and so on ... Basically you would bring in the geometry/basic shaders and then tweak it further with the sunflow syntax. The new file format I am planning will have the notion of updating existing objects (which is already possible via the API). So you can declare an mesh once (via a parser for your favorite file format), then attach sunflow specific attributes to it _later_ via an update command. Likewise the update can be done programmatically so it could be done inside a GUI. Pretty much anything can be changed and Sunflow will only rebuild what is necessary to support that change, not the whole scene.
Take a look at the SunflowAPI and the Parser interface to see how this works - its really quite simple. If anyone wants to write a parser for their favorite file format let me know, I will gladly include it.