Using other sunflow primitives

[Neon22]

In my attempt to use more sunflow primitives I have come across a problem that I can illustrate with the existing sphere primitive.
If I add the following object definition to the sc file:
object {
  shader none
  type sphere
  c 0 0 0
  r 1.0
}
Then I can make a substitution just like the generic-mesh box and so have many instances of the sphere.
This also works for torus etc.
However on using the rendertemplate all occurrences of {matrix} are not being evaluated if in a sphere definition. Instead they come through as:
transform col {matrix}
Is the Sphere handled specially ?
I see it has its own cx,cy,cz,r params but I assume those are available to all substitution rules ?

This works fine in an sc file:
%% geometry
object {
  shader none
  type sphere
  name "Sphere"
  c 0.0 0.0 0.0
  r 1.0
}
       
instance {
    name "Sphere0"
    geometry "Sphere"
    transform col 1 0 0 0 0 1 0 0 0 0 1 0 0 4 0 1
    shader "glass"
}
           
instance {
    name "Sphere2"
    geometry "Sphere"
    transform col 1.12763 0 -0.410424 0 0 1.2 0 0 0.410424 0 1.12763 0 0.730972 3.9 0.141397 1
    shader "glass"
}
       

[Neon22]

I have been testing all the other primitives and it looks like the order of the params is most important.
For all the primitives the transform has to come before the type definition.
refer here: http://sunflow.sourceforge.net/phpbb2/viewtopic.php?p=5208#5208
E.g.
even Julia sets and particles and hair all work (in 0.07.3 where applicable)
object {
   shader none
   transform col 0.001 0 0 0  0 0.001 0 0  0 0 0.001 0  0 0 0 1
   type julia
   name "Julia"
   q -0.125 -0.256 0.847 0.0895
   iterations 8
   epsilon 0.001
}

So it would seem that he substitution rules could be the same regardless of the type of the primitive

[Mikael Hvidtfeldt Christensen]

Hi,

The substitution rules available for the different primitives differ: for example the {radius} parameter used by the circle would not make sense for a dot.

The easiest way to see which rules are available are by looking at the source file (it is easy to read):
http://structuresynth.svn.sourceforge.net/viewvc/structuresynth/trunk/StructureSynth/Model/Rendering/TemplateRenderer.cpp?view=markup

For the sphere the transformation matrix is not present :-)

This is because it is internally represented by a center and a radius (4 doubles), instead of the full transformation matrix. This also means that you cannot make ellipsoids in Structure Synth (an annoying limitation - which makes same operations on spheres not work properly - e.g. resizing with different x,y,z). At some point I have to fix this, but I think I'll wait until after I've released what I have now (I want to get the camera export out - this makes the program *much* easier to use).

As for a possible fix, try using the qualifiers to create e.g. a 'box::sphere' object (if you do this the transformation matrix would be available).

Regards, Mikael.

[Neon22]

Cool. I see. Thanks for the link. Very useful. (I did not know {oneminusalpha} was there :) )
Yes I will use the box primitive in the meantime.

It seems that the following calculations are available for substitution but only allocated to specific object types:
{matrix}, {uid}, {r},{g},{b},{alpha},{oneminusalpha},
{x2},{y2},{z2}, {cx},{cy},{cz},{rad}
and for {cx} etc the parameters base.x may be the same calc as center.x, from.x, and v.x (as used in different primitives) because they are passed in differently for each primitive type.

So it doesn't look possible now but maybe one approach would be to:
- make a default class that the other, more special primitives, inherit from and for that one to define the matrix, uid, color, alpha values.

Further - it could be useful for some more of the values to be available in this base class (e.g. radius (which seems calculated based on the unit box)) for use in the substitution templates.

This way you would be writing less copied code and would have some more generality (seeing as the different renders like POV and Sunflow have different notions of primitives).

e.g. If I defined a torus then in my substitution rule in the rendertemplate file I could choose to use radius for the torus outer radius. E.g.
instance {
    name "{uid}"
    geometry "Torus"
    transform col {matrix}
        r 0.1 {rad}
    shader "glass"
}

But its just an idea - and I see that, right now, quite a few functions would need to be adjusted...

Cheers...

[Mikael Hvidtfeldt Christensen]

I don't think adding an object hierarchy for the template renderer is necessary - since these objects would be deleted immediately after they were serialized to text. Code reuse could can be accomplished simply by calling a standard function such as 'makeStandardSubstitutions(...)'.

The OpenGL renderer does use an object hierarchy (where everything inherits from Object3D), but while this base object does store color information, it does not store information like the transformation matrix - since this would be overkill for e.g. the dot object which only need to store three coordinates.

It is not terrible difficult to clean up and make the interface more uniform,  and at some point I probably will make {matrix}, {uid}, {r},{g},{b},{alpha},{oneminusalpha} available for all primitives. The {radius} will probably be removed, though. It is not well-defined if the local coordinate system has unequal axis sizes (i.e. no ellipsoids), so I think it has to go.

Regards, Mikael.