crafter-blender integration

General discussion about the development of the open source Blender

Moderators: jesterKing, stiv

bobthevirus
Posts: 0
Joined: Wed Jun 25, 2003 7:11 am

Post by bobthevirus »

neat, I like dia - very very cool... Anyway:

Image

where the orange are inputs, the blue is an action block, and the output behaves just like the output in crafter... We could possibly even use the same file format, though I don't know how extendable that would be?

Note that this is just an indication of the GUI capability's that would be used within blender, hooks would need to be added into the render to pass the inputs along to the matarial, which goes through and gives the renderer back the outputs... How does it work in that regard, wavk?

bobthevirus
Posts: 0
Joined: Wed Jun 25, 2003 7:11 am

Post by bobthevirus »

Some more random thoughts:

It would possibly be better to have individual spec, colour, reflection blocks visible in the matarials window... each with certain sliders on them. What would happen if one just wanted to use a block that someone had already set up, they would import the appropriate XML/bin/python file, and they would be able to add it to a particular matarial.

When tab is pressed with that block selected, edit mode for it would be entered, and appropriate parts from the diagram above would be shown ie. all parts that lead into say the "spec" block.

Matarial would be assigned to objects as they are now, and the texture channels would be inputs into the tree also...

levon
Posts: 0
Joined: Thu Jul 31, 2003 6:06 am
Location: adelaide

Post by levon »

wouldnt this break compatability to old blender files?? i think this feature would better be the basis of blender 3 rather then be put into the blender 2.x series.

bobthevirus
Posts: 0
Joined: Wed Jun 25, 2003 7:11 am

Post by bobthevirus »

Everyone seemed so dead-set against moving to blender 3 that It seems we may as well start doing these things anyway - who knows, once its done, maybe we can go to blender 3.0 (-:

Making a converter build would not be too hard I think - You'd just have to export the shader XML file using the standard options that are already availible - The logic of it woul be relitively easy... Basically if the old format had a phong shader then that shader with its settings would be stuck into a phong shader block in the new matarials, and ramps would be stuck into the appropriate normal/clour/spec/whatever part....... Having the old format readable by newer versions would be easy, and writing to the old format could probably be implemeted by creating a python script to read in XML files and convert them to a best-guess of what they should be in the older wersions.

About renderman: Converting our shaders into C files should not be much problem at all, so It would be a good idea to look at the renderman format so that exporters don't become too much of a problem... Should I try to set up a wiki so we have somewhere to do a proper design?

levon
Posts: 0
Joined: Thu Jul 31, 2003 6:06 am
Location: adelaide

Post by levon »

why not create a project at http://projects.blender.org/ for it

bobthevirus
Posts: 0
Joined: Wed Jun 25, 2003 7:11 am

Post by bobthevirus »

sweet, integrated wiki is cool - I'm away for a couple of days, but when I get back I will start on the project...

G

Money_YaY!
Posts: 442
Joined: Wed Oct 23, 2002 2:47 pm

Post by Money_YaY! »

updates?

bobthevirus
Posts: 0
Joined: Wed Jun 25, 2003 7:11 am

Post by bobthevirus »

Yeah wavk, I'd really like to know how easily crafter could just be slotted in - I was having a look at blenders code, and then my hdd dies, so I have lost my home directory, and haven't been able to anything since satuarday...

Anyway, as far as I can remember, I was thinking about data stuctures - Figuring that if I designed the XML and general object model, someone would be able to help me with the code...

These are the options I could see:
1. Use yafray's XML style - To me this looks like the easiest option, however it would make it more difficult to do the actual coding, and also more difficult to do the kind of flowcharting thing...

2. Use a system where each block has defined inputs, and defined outputs, and then specify which block each of the inputs should come from... This would convert almost linearlly(sp?) into code, and could be implemented probably even by me. It would be easy for the users to understand, but quite messy XML or whatever it gets saved as.

3. Use a heirachaclly system, like a tree. Each node has subnodes, and gets its inputs from the parent. I don't see how to make this work, but would welcome suggestions, as it would make the cleanest data structure.

Anyway, once my comp is back up, I will make a wiki page with pretty diagrams and XML data structures - not being properly schooled in software design, and then hopefully get at least some help with the human interface part of it. I would also love to know some of ton's concepts for 3.0, and whether these (rough) designs have any chance of actually being incorperated.

G

bfvietnam
Posts: 0
Joined: Wed Apr 21, 2004 8:54 pm

Post by bfvietnam »

bobthevirus wrote:Yeah wavk, I'd really like to know how easily crafter could just be slotted in - I was having a look at blenders code, and then my hdd dies, so I have lost my home directory, and haven't been able to anything since satuarday...

Anyway, as far as I can remember, I was thinking about data stuctures - Figuring that if I designed the XML and general object model, someone would be able to help me with the code...

These are the options I could see:
1. Use yafray's XML style - To me this looks like the easiest option, however it would make it more difficult to do the actual coding, and also more difficult to do the kind of flowcharting thing...
Maybe we could get some languages like Renderman and some
others together, and come up with something.. I'm pretty good at doing stuff like that.. Just yesterday I spent some time outdoors writing diagrams on paper and came up with a general design for coding Course material like for quizes.. Its funny because I thought about nodes pointing to other nodes, and wondered about how I was going to give one nodes address to another.. And I figured out a way I could do it relatively, by
turning the pointers into dependencies on other nodes.. Its making nodes
point to previous nodes, instead of having nodes use absolute pointers or labels to refer to other nodes.
2. Use a system where each block has defined inputs, and defined outputs, and then specify which block each of the inputs should come from... This would convert almost linearlly(sp?) into code, and could be implemented probably even by me. It would be easy for the users to understand, but quite messy XML or whatever it gets saved as.
Yeah.. It would be easy enough just to put labels on the nodes,
and have the inputs defined like this:

Code: Select all

<shader name="checkerboard">
<function name="check_shader">
<return>(x % 2) xor (y % 2) xor (z % 2)</return>  
</function>
<red function="check_shader">
</shader>
It needn't look like C.. We can take some freedoms.. Make functions
and symbols in the "shader" object implicit, like I didn't declare
what x, y, or z was.. They are just understoood to be absolute
world coordinates.. To declare a new symbol, we might use something like this:

Code: Select all

<var type=rgb name="black">0,0,0</var> 
That could of also been done like this:

Code: Select all

<var><type>rgb</type><name>black</name><red>0</red><green>0</green><blue></blue></var>
But the latter can be translated from the former, so why bother, the
first is better.. So make the XML simple and easy to translate for others
who want something more readable..

Code: Select all

<shader name="checker_bump">
<var  from=input type=shader as_name="chk">checkerboard</var> 
<var  type=normal name="nm"><use func="bump" parms="gauss,bidirectional,u,v">(chk.r + chk.g + chk.b)/3 * 256 
</use></var>
</shader>
I'm guessing at this, but it has to be pretty simple, and can be made simple.. It would probably require a non-xml parser for data/code between tags.. But this is not all that hard.. See Perl::RecDescent ..
But I think the best way is to look at languages like Renderman
and determine a way to replicate the functionality but without replicating
the syntax, we can use XML for that.. Then just make each shader
like an object, fill its scope with some implicit variables to make
coding easier but not such that it gets hard to come up with variable names that are not already predefined.. Also make the XML such that the there isn't a tag for every kind of data type.. Then later to enforce
correct data relationships we can write a higherlevel form of XML that
can be translated to this XML format.. Once for users who need things
written out in a human readable form, and the other for hardcore shader writers.. Have a DTD for each as well as something like "lint" for the shaders..

Lint is a program that corrects errors in C code by finding patterns of poor coding style.. Like assigning pointers without a cast..
But in this case it may be a shader that uses some symbols that are
common to another block but are not in the scope of the particular
shader type used.. So that shader writers are not beating their brains trying to figure out why a texture is not turning out a certain way, only to find that "normal" is not a predefined variable (for instance).

Also the shader blocks should allow one to add as many input and outputs as one needs.. But the type of inputs and outputs should be simplified to
vectors of integers, floats and such.. There is no reason to make this heavily typed..

If you need a juicy example I can probably come up with one, but I'm not very knowledgable about shaders.. Just it won't be possible to get away without some math expressions in the shader blocks.. To allow some flexibility, but the blocks should look like objects with a implicit
pack of predefiend variables or in this case, a predefined set of inputs
and outputs.. Like shaders should know what to do with "input.red" and
"output.red".. And the users should be able to add to this if needed..
Like "output.vector_matrix" .

bobthevirus
Posts: 0
Joined: Wed Jun 25, 2003 7:11 am

Post by bobthevirus »

Yeah, that is basically what my rough XML looked like, cept I was figuring mostly the methods of getting infomation between the shader blocks, as opposed to the maths - the maths could be done also using a
:

<op type="mod">
<parm>5</parm>
<parm>
<op type="add>
<parm>1</parm>
<parm>1</parm>
</parm>
</op>

which is equivilent to 5 % (1 + 1).... There is actually a semi-official schma for this somewhere - don't know if we want to use that or not, but it would make things easier. After work today I'll make a page on the wiki with links to all the different things that we can use as reference.

To integrate it into the renderer, there should, for each matarial not using defaults, be <spec>, <diffuse>, <transparency>, <reflection>( <etc> ) blocks. Textures would be internal to these - I'll have a look at renderman... these could be the bits that the renderer looks for to get the appropriate outputs - for spec and diff it would be output.RGB, transparency would depend on if raytracing was enabled or not - if no raytracing, it doesn't even look for the output.IOR or whatever - we should decide how low-level these output should be.

Getting information in would be simply a case of using preffixes - all b_**** variables are reserved, so that you have b_x, b_y, b_normal, b_zdepth, etc. This would help make it obvious what things are coming in from the renderer, and what are just there.

We should also think about how the GUI would be integrated - I'm in favour of each <var> haveing an optional <gui_element type="slider" min="0" max="1">, and then they all just get arranged in the visable block, with the variable name, and a slider. Tooltips and things could also be defined.

For the types of inputs and outputs, maybe float, int, bool umm, yeah, you get the idea... I don't think that inputs/outputs should be forced upon each block - there should just be say X ints (labeled Red, Green and Blue), X floats, and X bools - the inputs are defined in an <input name="red" type="int"> way, and then the GUI would show a connectty bit that has the shape of an int, and is labeled "red". This could then be used just like the other variables internally.

<output name="OAO" type="string">"G"</output>

blendix
Posts: 51
Joined: Wed Oct 16, 2002 1:00 pm

Post by blendix »

I think things are being overcomplicated here. My take:

If you need a shader language, use GLSL. It's a decent language, and the OpenGL ARB (architectural review board) has taken its time to evaluate it. No need to reinvent the wheel. Shaders will work nicely in the game engine, they can be created in external apps, and people with experience in this area will be able to transfer their skills.

If you want to store a graph in a .blend file, do it Blender-style. Use SDNA, ID structs, ..., so the nodes will be real library blocks. Info on those:
http://www.blender3d.org/cms/Blender_Ar ... 336.0.html

Then they can be shared between materials, .blend files, represented in the OOPS window, ... . Inventing some new way to store data, incompatible with the way the sources currently work, will make things very complicated.

A textual/xml reprensentation of all this might be useful, and could be offered as an alternative. Personally I don't think using a graphical language is a good idea. It will be too complicated for artists, and too cumbersome for coders.

bobthevirus
Posts: 0
Joined: Wed Jun 25, 2003 7:11 am

Post by bobthevirus »

GLSL is way underpowered - if we were going that way, we would be better off using renderman... Anyway, I don't think that it would be too compliated for artists, because there would only see the boxes like

Code: Select all

[phong]----
                |
                [and]------[spec]
                |
[ramp]------
part of it... which is simple to understand, and if they want more, then there are easy methods of getting furthur - adding more "blocks" in between, changing thresholds in ands, etc. Note that the XML I'm using here is just to represent the data structures, and while it would be useful to export it like this, I imagine that internally it would just be saved like the rest of it...

However, if it is really a really bad idea, I don't mind going with something else - it's just that this seems to be the first step to a more modular blender, and the first step to getting blender to integrate better with other environments, as the XML will be convertable (in)directly to renderman language, yafray, etc. I don't know, what do other people think?

[edit]
regarding the dna, structs etc... My main purpose in pushing XML is that it can be broken down, so that there are multiple levels of complexity - you have the topmost, which is like my crappy diagram above, and then the next level down, which shows the parts of user-defined blocks (want to use bfvietnams l33t chrame shader, as part of your aliminium one? Easy, just import that block, and connect it up in the appropriate places... Who cares that internally there is whole heaps of complicated vector arithmatic going on), then, the next level is showing everything, each and, or, mul, mod and dot-product...

As far as I can see, the thing that most prevents thing kind of grouping at the moment is the dna structure, but thats probably becuase I only think in an OO kind of way, and have difficullty working out how the existing stuff works internally. If you or anyone else can provide a nice framework of interconnected nodes, that can group up and appear at a range of complicatedness to the end user, so much the better, and then that can be used... If this matarial stuff can become a model for a more modulized blender, then that is what I really want (I'm trying to sneak a concept for blender3 up on users unawares, but I understand that I haven't seen the real plans, which are probably way better than anything I could dream of)
[/edit]

Money_YaY!
Posts: 442
Joined: Wed Oct 23, 2002 2:47 pm

Post by Money_YaY! »

I as a user do not care what is behind it. I would just like to know how fast will it be. Like how fast will it render out a clean shpere to see the demo shader.

The Blender shader is blocky at best and small, but quite fast. The Crafter program uses Yafray so the demo renders are kinda slow but much nicer looking. :?

I just want to hope that speed is an issue at hand to,.

bfvietnam
Posts: 0
Joined: Wed Apr 21, 2004 8:54 pm

Post by bfvietnam »

PrePS- Check out this link:
http://www.spannerworxonline.co.uk/

Does this stuff sound familiar? There is a description on this
page of a method of connecting game objects together to make
games.. Doesn't this sound a little bit like crafter and the shader
system idea? Really this game engine concept is a event driven simulation with interconnecting objects that signal each other through method calls.. Crafter would evaluate all modules at once, it wouldn't have objects that
communicate in both directions, but it may be the case the visual part of crafter could be used to model such relationships say in game blender..


--------------------
Blendix.. I don't think the graphical language will replace what shader languages do, it will just encapsulate them in a way that makes them useful to users, and easy to combine.. There is a technology called CORBA, that is used to encapsulate programs in different languages like C and Java, and Cobol in ways that enterprise systems can add object oriented technology without changing the languages.. I don't suggest using CORBA for realtime software, and its not designed to replace languages.. ITs a facilitator of integration between distributed computers and applications that were not designed to work together.. ITs a model of how I think crafter could be designed to make disparate shading languages work together, in a way that doesn't put the users at the mercy of any particular vendor.. Shader languages like Cg were designed specifically to leverage consumers of competing products like ATI Radeon's, to compare the qualities of Radeons to Geforce4's.. Where Cg is optimized for NVidia cards and not for Radeons.. But if you are a Geforce developer, you have to manage both Cg, and DirectX Shader technology and other shader languages.. Wouldn't it be better if you could make this accessible to users and manage it so that multiple cards could work together on a render..
Crafter is a visual interface now.. But later it could develop into a way to make shaders for any platform or even hybrid shaders, because its got to be possible to reduce shaders to pluggable components. I've proven before that even languages like C can be reduced to tree graphs.. So what is wrong with using a graph to express an algorithm?

Now you could have sub-graphical languages for describing math, that goes into the modules.. But I don't expect the users are going to want to deal with that.. It seems to be the case taht when I talk about something else like this, people think "oh I like what I've got, why ruin that".. Well you don't have to do that.. It possible to make one default and the other an option.. Its called Overloading.. ITs an object oriented design concept..
Rather than design the system to use specific things, why not fool it into thinking its working with something when really its a hook to allow other kinds of models that can use a similar interface without compromising
the existing tools.. This is why Blender lacks the flexibility of Maya, its dependent on static relationships that can't change easily.. But there is no reason why it has to be like this.. I don't think this will over complicate
blender.. I think the idea here is to go in two directions, make blender's shading system more flexible while reducing the complexity of how it does things, but without compromising what it has.. This can be done and its about understanding what blender does with shaders and how to substitute crafter in for that.. Then eventually as time goes on, it will be able making blender capable of doing other thigns that it can't do now, by expanding the shader API to have access to components in blender..


Code: Select all

<op type="mod">
   <parm>5</parm>
   <parm>
      <op type="add>
         <parm>1</parm>
         <parm>1</parm>   
   </parm>
</op>
Yeah this is a bit complex.. I was saying that this could be represented
simply.. As you said.. It can be expanded out to this, but someone
coding this won't want to use this, they will want to use the math expression.. Its easy to write expression evaluators that can reduce to XML like this, but its just that for expressions like that in XML are only easier for machines to parse not easy for coders or humans to understand without placing a few fingers on teh monitor screen.. This is where a symbol with some plus signs and division signs is best and XML loses its value.. I think it would be best to make the XML in a form that is readible yet practical, to take advantage of the modular/encapsulating capabilities that make XML powerful.. Simple words, like names and types, should be as attributes.. The main subject (the expression, inputs, images, etc.) should be encapsulated in the tags. And ideas that are implicit like surface normal, globals, and such should be implicit variables in the scope of the tag block.

Nesting of same named tags, should be kept minimal unless it makes sense.. Like

Code: Select all

<shader name=checker><shader name=checker>
will probably never show up in a real solution..

However

Code: Select all

<shader name=checker>
...
...
</shader>
<shader name=checker2 extends=checker>
</shader>
or

Code: Select all

<shader name=checker>
...
...
</shader>
<instance type=checker name=checker1></instance>
<instance type=checker name=checker2><input>checker1.value</input></instance>
would be more likely.. I mean, its better, in terms of parsing the XML, to not have similar tags to be nested more than once in another, unless its needed.. If you need to put a shader model into another shader model,
like encapsulate it, you can declare the two in linear and have one inherit from the other or have one put in the other as a object instance.. This is like in the UML diagrams:

http://www.holub.com/goodies/uml/index.html

I'm saying use Aggregation and (Implementation) Inheritance versus Composition..

In PHP code, that I'm more familiar, here is how Inheritance, Aggregation and Composition (not sure if the composition version is representable in php) is represented:

Inheritance:

Code: Select all

class stuff extends otherstuff { 
     function method () {  // overloads method of same name in otherstuff..
    }
}
Aggregation:

Code: Select all

class stuff { 
      var $otherstuff_pointer
      function obtain_otherstuff($otherstuff) { 
               $otherstuff_pointer = $otherstuff;
      }
}

$a = new stuff(); 
$b = new stuff(); 
$a->obtain_otherstuff($b);
Versus Composition:

Code: Select all

class stuff { 
     var $somestuff;
     class otherstuff{ 
     }
     function access_otherstuff() { 
          $this->somestuff = new $this->otherstuff(); 
     }
}
Or worse yet, the class stuff is in another class of the same name, which is just confusing.. And tough to parse.. Especially in XML.. You can do stuff like this in C and C++, its done to protect scope global scope.. But you are using objects, there isn't a global scope to really worry about, because you can control that.. In fact if you wanted to.. In Crafter you could have a module that manages all global variables for all the other modules, the inputs being implicit to the other modules.. It might be possible to say make the concept that some modules use one module for globals and another module for other globals.. It would be like an aggregation relationship where the object uses outputs of an aggregate module as inputs.. Or you could make two kinds of modules, those of global module class 1, and of global class module 2, but both modules implement the same interface so they can be substituted in the same place without disrupting a module configuration and without complicating the global scope for all modules.. And without overcomplicating the design with wires running from the global variable objects to all the modules that inherit from or use the global variables from those objects..


There should be overloading, like as you say, an input could have a slider instead of a reference to some external variable from another module.. Or it could be a reference to a model, or to waveform output from a sound generator, or an input from some external source liek a radio antenae, who knows, but it shoudl be possible withotu disrupting the way the shader works, just by substituting the input of a constant or a variable with a function.

It may even be the case that as people really use crafter, the slider option becomes the default assumption for inputs.. Like a slider may become like a valve that determines the amount of influence an input has, thus a slider is an attribute that scales.. The slider could become implicit (all attributes with a scale are modified in crafter with a slider). and when there is no input, the default input is 100% and the slider varies this.. I'm not saying it can't exist in the language that you can't specify a slider for inputs, but to simplify the the language it might be better if the the slider was a default method of adjusting inputs for modules, with the option to control say the range of the slider or to support other kinds of input controls, or the default input value.. Like how in blender, every numeric value can be adjusted by shift-clicking it or clicking on either the left or right side of the value, but in the code its just a widget that the UI uses its
implicit in the details of how the numeric parameters are modified, anywhere there is a number, there is this behaviour that a user can expect. For coders, overloading is a method of making coding easier.. Rather than having to add widgets for every module.. But if done this way, sliders are implicit valve control of inputs, then when the shader coder wants finer control over this, giving a slider as input should override the existing slider (so that users don't have to deal with two sliders for an input).. This would be like the XML interpreter substituting a default slider
for uninitialized inputs..

Money_YaY! wrote:I as a user do not care what is behind it. I would just like to know how fast will it be. Like how fast will it render out a clean shpere to see the demo shader.

The Blender shader is blocky at best and small, but quite fast. The Crafter program uses Yafray so the demo renders are kinda slow but much nicer looking. :?

I just want to hope that speed is an issue at hand to,.
You can use blender now to render out a clean sphere.. That won't
change, even then.. At worst, Blender will need a seperation of code that
seperates the existing renderer from the render system, making the
system accessible through a shader API.. That will have to be done.. That can be done without much cost dependent on how much data is passed between the shader system and blender's rendering system..

Also blender's renderer could continue to exist in the system.. Just as it does now.. Just that parts of the rendering system would have to have conditional code that determines which shader to use when computing the color of a surface (internal shader vs. crafter shader, or external shader {plugin})..

Originally I think Ton planned to have blender use OpenGL2.. But I don't know if that's going to happen.. Crafter could be designed to make fragment shaders for OpenGL2.. The advantage is being able to give users access to some of the low-level functionality and arrange shader pieces themselves.

The shader system as I understand it, handles coloring of surfaces on objects based on lights, reflections of light, the mapping of images to the surface, the manipulation of the surface normals (bump maps), and possibly the modification of the geometry at render time (displacement maps).. Graphics cards have two kinds of fragment programs, fragment shaders (dynamically compute the color of surfaces, compute 2D image processing effects like convolution matrix operations) and fragment modelling operations (simple IK solutions, tesselation of NURBS/Subdivision surfaces to polygons, displacement maps, particle effects, etc..). Crafter could be used to make both kinds.. But I don't know the limitations of this.. Like what can be done visually and what requires math and expressions, but having an option to break this up visually into pieces that can be arranged, makes it more accessible to average users who can't code, and that's a good thing.. It means you can better express your ideas.. Its even good for the coders because they can play with shading models without having to code, compile, test, code, compile, test..
Last edited by bfvietnam on Wed Sep 08, 2004 1:24 pm, edited 1 time in total.

bfvietnam
Posts: 0
Joined: Wed Apr 21, 2004 8:54 pm

If I lost you guys in the last message..

Post by bfvietnam »

I misunderstood a composition pattern from UML.. Its not a delcaration
within a declaration, but is like crating an object and referring to that
internal to the encapsulating object.. You can see this int eh UML card..
I was using this to express a problem I've found in my own work with XML, and that parsing XML interatively as opposed to doing it recursively which is mroe robust but complex.. There is a function in PHP that turns XML
into two arrays one a tree of nodes that specify tags that nest other
tags, and tags that contain only data.. It labels the tags with data as being single nodes "complete" and those with nested tags as "open" or "close"..
The actual function is "xml_parse_into_struct()" you can read the code description here:

http://us2.php.net/manual/en/function.x ... struct.php

Anyhow, it creates structures that look like this in PHP:

Code: Select all

Index = Array
(
    [PARA] => Array
        (
            [0] => 0
            [1] => 2
        )

    [NOTE] => Array
        (
            [0] => 1
        )

)

Vals = Array
(
    [0] => Array
        (
            [tag] => PARA
            [type] => open
            [level] => 1
        )

    [1] => Array
        (
            [tag] => NOTE
            [type] => complete
            [level] => 2
            [value] => simple note
        )

    [2] => Array
        (
            [tag] => PARA
            [type] => close
            [level] => 1
        )

)
thats from the XML:

Code: Select all

<para><note>simple note</note></para>
Which is really easy to parse.. with for-loops..

Code: Select all

a
$i = 0;
for ($x = $Index['Para'][$i] ; $x < $Index['Para'][$i+1] ; $x++) { 
    switch($Vals[$x]['Tag']) {  
     case "Note": 
           $Notes[$notec++] = $Vals[$x]['value'];
     break;
    }
}
However if note, contains a note.. Like this:

Code: Select all

<para><note><note>something else</note>another thing</note></para>
It would make the code harder.. Maybe its just easy enough to use a
recursive parser like:

Code: Select all

function para($xml) { 
     list($first, $rest, $last) = unwrap($xml); // ($first, $rest, $last) = $xml
     if (($first="para") && ($last = "para")) {
          return as_array(para($xml));
     } elseif (($first="note") && ($last = "note")) {
          return as_array(note($xml));
      } 
}

function note($xml) { 
     list($first, $rest, $last) = unwrap($xml); // ($first, $rest, $last) = $xml
     if (($first="note") && ($last = "note")) {
          return as_array(note($xml));
     } elseif (($first="para") && ($last = "para")) {
          return as_array(para ($xml));
     }
}

para("<para><para></para></para>"); 

I'm sure there is probably a better solution recursively, Just its not obvious to me how to parse this in XML.. I'm only now using XML..
I figrued it should be easy to parse and derive new structures rather than having to think recursively and come up with a robust parser that can handle embedded replication of the same tag name.. People don't normally think like this, so why should they have to wotk this way..
And one method of had about going about this, is to declare objects
and object relationships linearly.. Which I think would make the coding
of parsers easier for this xml, such that you wouldn't have to use recursion.. ..

Post Reply