 |
Radium
www.radiumrenderer.com
|
| View previous topic :: View next topic |
| Author |
Message |
droid
Site Admin
Joined: 19 Sep 2006
Posts: 1069
Location: UK
|
 Posted: Tue Mar 13, 2007 8:34 am Post subject: v0.10 - changes to .scn format |
 |
|
First of a few documents describing changes to v0.10. This one's mainly for Hiroto (in case you want to update the Cheetah exporter for v0.10) 
settings
One new render setting:
mlt_max_change <double n>
Defines the maximum step size used by the Kelemen mutation strategy.
0 < n < 1.0 (but try to maintain 0.05 < n < 0.02)
Default is 0.02
Existing settings are used to define new MLT parameters...
mlt_q_newpath <double n>
0.0 < n < 1.0
The probability that a large step (i.e. brand new path) is chosen
mlt_q_bounce <double n>
0.0 < n < 1.0
The probability that a ray bounces off a diffuse or phong BRDF. Setting this to 0.0 results in a direct-light-only render. Setting it to 1.0 should NEVER be done
The following are the same as before:
mlt_max_consec_reject <int n>
mlt_max_bounces <int n>
filter_samples <true/false>
The following are no longer used (but will still be parsed to maintain backwards compatibility):
mlt_min_bounces <int n>
mlt_max_consec_accept <int n>
mlt_q_caustic <double n>
mlt_q_ind_caustic <double n>
mlt_do_ind_caustic <true/false>
material
Changes to support material maps and material bands...
A material map is defined by specifying the map used to choose material bands, e.g.
| Code: | material_map noise {
scale 0.5
}
material_map dent {
0.4
scale 2.0
} |
Radium maps are just a function that returns a value between 0.0 and 1.0 based on the UV (for UV maps) and the intersection point (for 3D maps). Images return a value based on pixel luminosity so beware of HDR images (where luminosity can be greater than 1)
Material bands are specified as follows:
material_band <double n> <material>
e.g.
material_band 0.2 {diffuse 0.8}
Note that, unlike colour bands (which specify a map value range), only the map value threshold needs to be defined. Any map values equal to or less than the threshold will be mapped to the specified material. This means that the material bands need to be defined in ascending order of threshold value.
Here's a full example of a material modulated by a noise function with resolution of 10cm, with 3 bands:
| Code: | material m_swirl = {
material_map noise {
scale 0.1
}
material_band 0.3 {diffuse <0.8,0,0>}
material_band 0.6 {diffuse <0,0.8,0>}
material_band 1.0 {diffuse <0,0,0.8>}
} |
BRDFs
The new BRDF "phong" is specified as follows:
phong <colour diffuse_colour> <colour specular_colour> <double exponent>
The diffuse colour will be fresnel-modulated as appropriate (based on the phong exponent and the IOR of the containing material). The specular colour defines the colour when viewed at 0 angle and is fresnel modulated in the same way as the "reflect" or "specular" BRDFs.
Maps applied to the phong BRDF will only affect the diffuse colour. I know this is a limitation but I'll add support for a specular colour map very soon.
Try not to use "specular" any more.
There's also a new "null_material" BRDF, which just passes the ray straight through with no changes. Intersecting a null_material BRDF still results in processing overhead, it's not true empty space as far as the rendering algorithm is concerned.
Mesh definition
The old concept of defining local mesh vertice, normals and UVs still applies, but there is a new way of defining meshes to support .OBJ format...
(Before any meshes are defined...)
| Code: | global_verts {
<int num_vertices>,
<vector>
<vector>
....
<vector>
<vector>
} |
| Code: | global_norms {
<int num_normals>,
<vector>
<vector>
....
<vector>
<vector>
} |
| Code: | global_uvs {
<int num_UVs>,
<vector>
<vector>
....
<vector>
<vector>
} |
The above three blocks define global vertices, normals and UVs which will be used by subsequent mesh definitions. Only specify these once in the .scn. UV vectors can be specified as <u,v> or <u,v,x> (the x will be ignored in the latter case).
NOTE: A comma after the count value, no commas after the vectors!!!
To use the global vertices in a mesh definition, simply use a shape modifier of the form....
| Code: | faces {
<int num_triangles>,
<triangle definition>
<triangle definition>
....
<triangle_definition>
} |
<triangle definition> can be one of the following:
Simple triangle with a material
tri_m v0, v1, v2, <material>
Smoothed triangle with a material
tri_sm v0, v1, v2, n0, n1, n2, <material>
UV-mapped triangle with a material
tri_uvm v0, v1, v2, uv0, uv1, uv2, <material>
Smoothed, UV-mapped triangle with a material
tri_suvm v0, v1, v2, uv0, uv1, uv2, n0, n1, n2 <material>
Where...
v0, v1 & v2 are integer indices into the global vertices
uv0, uv1, uv2 are integer indices into the global UVs
n0, n1, n2 are integer indices into the global normals
The first index is always 0 (not 1)
A sampe .scn with global vertices available on request
Ian. |
|
| Back to top |
|
 |
scorpius
Joined: 27 Sep 2006
Posts: 38
Location: NJ, USA
|
| Posted: Wed Aug 22, 2007 10:14 pm Post subject: |
|
|
I just posted about normals, and came across this post, which is exactly what I was looking for.
Is there an example of the old way of defining local mesh vertice, normals and UVs? |
|
| Back to top |
|
|
droid
Site Admin
Joined: 19 Sep 2006
Posts: 1069
Location: UK
|
| Posted: Thu Aug 23, 2007 10:25 am Post subject: |
|
|
Hey Scorpius, long time no see...
Here's a snippet for you of the way local UVs were defined in a mesh...
| Code: |
shape sh_Plane_006 = mesh {
material_list {
1,
m_dilbert_print
}
vertex_list {
4,
<-8.570902,198.599182,22.256334>,
<-8.602880,197.019653,22.256334>,
<-10.710391,197.062332,22.256334>,
<-10.678413,198.641861,22.256334>
}
face_indices {
2,
<0, 2, 3>, 0,
<0, 1, 2>, 0
}
face_uv {
2,
<1.000206,1.001930>, <-0.000206,0.002216>, <0.000598,1.002734>,
<1.000206,1.001930>, <0.999403,0.001412>, <-0.000206,0.002216>
}
}
|
I think that's what you're looking for. I believe it's possible to specify local UV vertices as indexes as well as per-face but it's been so long since I looked at that code I don't know for sure...
Ian. |
|
| Back to top |
|
|
scorpius
Joined: 27 Sep 2006
Posts: 38
Location: NJ, USA
|
| Posted: Thu Aug 23, 2007 2:15 pm Post subject: |
|
|
Yeah, I haven't been here for a while, but I haven't forgotten about Radium.
So the (per-face) normals could be specified like so:
| Code: | face_norms {
2,
<xyz>, <xyz>, <xyz>,
<xyz>, <xyz>, <xyz>
} |
|
|
| Back to top |
|
|
droid
Site Admin
Joined: 19 Sep 2006
Posts: 1069
Location: UK
|
| Posted: Thu Aug 23, 2007 3:15 pm Post subject: |
|
|
| scorpius wrote: | Yeah, I haven't been here for a while, but I haven't forgotten about Radium.
So the (per-face) normals could be specified like so:
| Code: | face_norms {
2,
<xyz>, <xyz>, <xyz>,
<xyz>, <xyz>, <xyz>
} |
|
Silly me, I was in such a rush to leave this morning, I didn't realise you were talking about normals (not UVs).
The keyword is "face_normal"...
Ian. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
