Archive for the ‘spot’ tag
2D Patterns
Been working on a small Javascript library for generating 2D procedural patterns (with the ShaderBuilder in mind).
See the progress here or click on the image below.
Shader Builder Progress
Significant progress in the LxEngine ShaderBuilder. The builder now supports Phong shading and procedural patterns such as tile, spot, diamond, and wave.
Below is a quick, low-quality demo video of the work-in-progress LxEngine Tutorial 3, which loads of a Blender model and allows the user to cycle through a set of shaders to apply (each material defined via a concise JSON description in the XML file):
Video
Note how the specular highlights on the different, individual tiles of the checker patterns are not the same for the red checker materials. This really is a nested procedural! Each tile in the checker not only gets a color, but has its own Phong specification. Also check out the bright highlights on the last Phong checker: that’s actually another level of nesting where a border pattern adds much brighter specularity to the edges of the tile.
Stills
Here is the Stanford bunny shaded with a checker pattern with a nested wave pattern:
Here’s the Suzanne model from Blender, shaded with the normal-based shader:
Finally, here’s the classic Utah Teapot with a spot pattern:
What’s Next?
I have a host of todo’s lined up, but…any reader suggestions on what next to add to LxEngine? I’m looking for something that – while still somewhat feasible for a single person to implement – would help the engine stand out as having potential to be a top-of-the-line engine someday.
- Continue the shader work and add a Tutorial 4 with even more advanced multi-pass, multi-layer rendering and animation?
- Further Bullet Physics integration to demo how that library can easily and effectively be used within LxEngine?
- A miniature MineCraft procedural world sample with an infinite world with a sky, rain, and snow since MineCraft is all the rage?
- A simple FPS to demo a complete game with LxEngine?
- Something completely different?
Effects Sub-Project Complete
One more shader fragment for the tile procedural and an updated data file later:
Definition of “Complete”
According to the objectives of this sub-project, it’s fair to say the rasterized versus raytraced images results match sufficiently to call this sub-project done. The remaining mismatches are primarily: (1) lack of shadows, (2) light position mismatch, (3) color tweaking. Regarding lack of rasterized, soft, area light shadows, that is a sizable sub-project in itself; I’d like to pursue some other areas of the code before embarking on that one. Regarding the light position mismatch, that’s a defect in the ray-tracer code: there’s no real learning value in attempting to compensate for that defect. Regarding color tweaking, it’s close enough that I’m satisfied with the results.
There are plenty of areas for further improvement (there always are!) such as bitmap texture support, light shaders, nested uv spaces, shared variables, etc. However, in the interest of exploring different areas of graphics code and based on the aims of this particular effort, I’m labeling this sub-project complete.
A complicated, nested procedural example
I’m fairly happy with the system’s capabilities. For example, the foremost sphere in below image demonstrates a fairly complicated setup. The diffuse channel contains a nested procedural: there is outer checker pattern which defines an inner checker pattern for one tile and a spot pattern for the other tiles. Furthermore, the UV scaling on each level varies (the inner checker is 2×2, the inner spot is 3×4). Lastly, the specular channel is completely independent as it defines a checker pattern of it’s own with a completely different UV mapping.
Here’s what the corresponding data file for the nested procedural sphere looks like (in the JSON scene format):
{
description : "Nested checker",
type : "plyfile",
content : "sphere.ply",
style : {
scale : 0.00392156863,
translate : [ 0.0, -1.25, 0.5 ],
exponent : 128,
material : {
phong : {
diffuse : {
checker : {
primary : {
checker : {
uv : { spherical : { scale : [ 24,9 ]}},
primary : [ .4, 0, 1],
secondary : [ .2, .6, .3],
},
},
secondary : {
spot : {
uv : { spherical : { scale : [ 36,24 ]}},
radius : .45,
primary : [ .5, 1, 1 ],
secondary : [ 0, 0, .1],
},
},
},
},
specular : {
checker : {
uv : { spherical : { scale : [ 32,16 ]}},
primary : [ 1, 1, 1],
secondary : [ 0, 0, 1],
},
},
}
},
}
}
Effect System Support
A quick look some of what the system currently supports:
- Pluggable shader fragments
- Current Mappers cube, spherical, spherical-xy
- Current Procedurals: checker, spot, tile
- Current Base Shaders: phong
- Fully dynamic material shader generation
- Shaders can be nested arbitrarily (to the limit of what the video card can support for a single shader)
- Objects can share the same procedural and mapping for diffuse and specular, or have unique definitions. The correct shader will be generated automatically.
- If two materials have the same structure but different parameters, the system automatically reuses the existing shader and simply changes the uniform variables.
- Inherited Stylization in Scene Graph
- Child nodes automatically inherit any parent attribute, unless the child overrides it. Example: the three stacked cubes share a parent that defines the stylization; the children only define the transform and geometry.
- Shader fragment definitions can automatically pick up these style parameters. Example: the checker procedural automatically grabs the current primary and secondary colors defined by the parent if it is not given explicit values to use.







