It’s been many months since the last public release of Prim.Blender. With the summer months rapidly approaching here in the States, interest has resurfaced in this project.
As original project founder and maintainer, I no longer actively develop Prim.Blender for personal reasons. However, for those who are curious, or otherwise interested, I wanted to share my ideas and tests over the past few years.
This should be considered the roadmap that never was: feature ideas, fixes, and tasks from my agenda, and those suggested to me by others.
The basic outline is as follows:
Feature Ideas
* Textures and Render Pipeline
* New Sculpty Sizes
* Primitive Animation Sequences
* Sculpty Animation Sequences
* Light Render Tests
* Texture Projections
* LSL and Link Impostering
Bug Fixes
* Refactored Mirror Support
* Fixes to Primitive Params
* Prim Torture
* Megaprims
* UI Cleanup
* Benchmarking and Expanded Use Cases
* Code Refactoring
Dev Tests and Errata
* More Thorough Regression Tests
* Menu Integration
* 3D Model Import and Export
* Documentation
For details, see below.
—
Feature Ideas
Textures and Render Pipeline
I’d always wanted to implement textures for Prim.Blender. While this is trivial for sculpties, regular prims are a very different animal.
Now, Prim Composer already has texture support, so it wouldn’t be a huge leap to port that support to Prim.Blender. The devil is in the details, however; particularly, in mimicking the various display and render anomalies of the Second Life client.
Furthermore, I always came back to wanting to be able to bake robust materials from Blender straight to the prim surface. This is plausible and indeed, not terribly difficult, but would require constant monitor of Blender’s features and development path for the script API.
Effectively, texture support is a job in itself.
—
New Sculpty Sizes
Back in version 1.22 of the Second Life client, Qarl added the ability to create “non-square” sculpties to Second Life. By this, the dimensions of the sculpty map would define the number of faces used.
Prim.Blender has support for this at the backend already, as I’d effectively forked Domino Marama’s code.* However, certain improvements and testing are required on Domino’s code to prevent the functions from crashing.
—
Primitive Animation Sequences
Back in March of 2005, I drafted an animation system for prims. The basic idea was to use regular prims to play various BVH animations, as a means for vehicles, visual effects, and autonomous avatars.
Being able to specify the animation of prims using Blender motion data would be a logical extension of this project. The trick would be programming such a system fluidly, accounting for the speed that Second Life renders motion data (ie, llSetPos and llMoveToTarget).
—
Sculpty Animation Sequences
Similarly, being able to bake in visual effects to sculpties would be a win for Blender users.
Domino’s tools already allow for this, provided one has significant knowledge of Blender’s vertex animation and baking systems. As the aim of Prim.Blender is to make these tools more accessible, being able to build animation sequence data into a series of sculpty maps automatically would be a significant step forward.
—
Light Render Tests
With the new changes to the lighting system to enable real-time shadows and dynamic lighting effects (AKA, deferred lighting), it would be a big win to have Blender lights translate to Second Life.
Once again, an eye for nuance would be required, along with working very closely with the Render Pipeline client as it develops.
—
Texture Projections
Another new feature of the render pipeline build is the ability to project textures onto another surface.
This is technically possible in Blender, and would be very useful for testing effects prior to committing them in Second Life.
—
LSL and Link Impostering
Several of the best texture and render effects are done through the use of LSL scripts, including some of what’s listed above. Being able to imposter the particle system, linking system, and various scripted effects would be very helpful to tweaking models and textures in Blender.
While technically part of the XML prims specification included with this project, script contents add a whole new dimension to working with this tool. Specifically, they would allow developers to test their builds and sandbox new ideas outside of Second Life.
A possible implementation of this would be to migrate some of libSL’s code into this tool. However, such a project is a major undertaking. The farthest I got was the initial scope and skeletal implementation.
—
Bug Fixes
Refactored Mirror Support
Prim.Blender currently mirrors sculpties along all three channels: Red (X), Green (Y), and Blue (Z). As implemented by Qarl, Second Life now handles the mirroring and inversion of sculpties on the fly, but in the case of mirroring, only along the X-axis.
Effectively, the refactored code would be nothing more than two bits to specify mirror and invert, just like the current sculpty spec. Normals would need to be flipped appropriately, and mirroring functions handled accordingly.
The basis of this change would be purely to save on textures when uploading to Second Life.
—
Fixes to Primitive Params
As pointed out by several residents, various changes to the client code have caused a bit of drift between my own functionality and that of the Second Life viewer. In addition, several bugs in my own primitive params exist, particularly on coverting certain values and with the size of spheres.
Ideally, such work would be paired with refactoring the primitive code itself, as it’s currently a bit of a mess. See “Code Refactoring” below for more details.
—
Prim Torture
My tools have always assumed no support for prim torture. In light of sculpties and very small prims, however, this assumption would to well to be revised, for residents that continue to make use of these features.
—
Megaprims
Currently, Prim.Blender does not support megaprims. However, this support would be trivial to implement, given a list of fundamental megaprim sizes, and the ability to include them with copies of the importer.
Personally, I have mixed feelings on revising the code to support megaprims, since they’re not an explicitly supported feature by Linden Lab. However, residents have proven the usefulness and desire to create efficient builds using them, and I’m not one to argue.
—
UI Cleanup
The UI code for Prim.Blender is a bit of a mess. In addition to minor quirks and timing issues, the current assumption of using a timer instead of an event for primitive updates should be revised. This was originally implemented for (now) very old Blender API support.
—
Benchmarking and Expanded Use Cases
Several residents have reported various problems using Prim.Blender with functions of Blender, including Ctrl-Z (Undo), texture and object manipulations, and combining with other scripts.
Expanded use case scenarios, tests (see below), and work with the Blender interface itself would fix a lot of these issues.
—
Code Refactoring
The entire code tree needs refactoring. When I originally envisioned Prim.Blender, I designed it as monolithic code written in much the same way as a book. Given my programming experience has dramatically improved over the years, I realize the need to convert the entire code tree into a more modular, flexible structure than that which currently exists.
Specifically, every direct function should live in its own logical file, original assumptions should be documented in the code tree and tested against at the function level, and the entire tree should be refactored to reflect current assumptions of both the Linden code tree and quality.
In particular, this project was written before the client source was available to residents. Ideally, this code would use the same documentation standards and structure as the client tree, and quite possibly be merged into a section of it.
—
Dev Tests and Errata
More Thorough Regression Tests
The regression tests for Prim.Blender are very, very weak at the time of this writing. In order to ensure robust code, the entire tree MUST be tested rigorously at the unit, module, and integration level, and tested again with every version regressions.
Currently, my tests are generally topical, at the integration level. Tests should be interleaved within the code tree, allowing for easy testing and verification.
—
Menu Integration
Prim.Blender currently exists as its own menu system, residing in the script window of Blender. In addition to relying heavily on this system not crashing, the system should rely more on Blender’s own import and export logic than its own duplicated “Save” functionality.
Effectively, the “Save” button should become an export to prims, “Load” to import, and the user should expect to just save the .blend file for the entire set.
Much of this currently works in the public build, but has not been thoroughly tested.
—
3D Model Import and Export
Over the past few months, I’ve worked with various ideas on how to convert an entire Blender scene into a set of sculpted prims. In addition, this method would work to “combine” multiple primitives together into a single, sculpted unit.
All one would need to do is compute the outer edges of a multi-primmed or mesh solid. Next, sculpties should be applied to the surface area of the model as a series of “patches”, following the loops of the solid until all faces are accounted for.
Essentially, this method uses sculpties to “patch” a model together. While issues regarding seams exist, this would allow one to import 3D models directly from Blender into Second Life, complete with textures and baked material properties.
Another option would be to simply have a sculpted prim “conform” to the surface of a mesh solid or prim set. Such a system would be very good for “impostering” a series of models in very few prims, but would take a severe hit to detail.
—
Documentation
The final prong of this project that I never managed to get to is robust documentation. Domino Marama and Gaia Clary have done a terrific job of documenting their own sculpty system using video tutorials, written documentation, and multiple help threads on the forums.
My own project somewhat pales to this work, in that it’s been a sole labor of love by one person. Future maintainers should take a stab at thoroughly documenting this project at the technical, user, and tutorial levels.
I will admit some jealousy, in the hard work Gaia put into documenting Domino’s tools. But such is the way these projects work out.
—
Thanks for reading. I hope this documentation serves to help future developers work with my tool, and develop future external tools for Second Life.
* I’ve edited Domino’s tools to upload non-square sculpties right out of the gates, and refactored a bit of the code. Should anyone be interested in this revised build, please let me know in comments or by email (tom plus the domain of this page).
As original project founder and maintainer, I no longer actively develop Prim.Blender for personal reasons. However, for those who are curious, or otherwise interested, I wanted to share my ideas and tests over the past few years.
This should be considered the roadmap that never was: feature ideas, fixes, and tasks from my agenda, and those suggested to me by others.
The basic outline is as follows:
Feature Ideas
* Textures and Render Pipeline
* New Sculpty Sizes
* Primitive Animation Sequences
* Sculpty Animation Sequences
* Light Render Tests
* Texture Projections
* LSL and Link Impostering
Bug Fixes
* Refactored Mirror Support
* Fixes to Primitive Params
* Prim Torture
* Megaprims
* UI Cleanup
* Benchmarking and Expanded Use Cases
* Code Refactoring
Dev Tests and Errata
* More Thorough Regression Tests
* Menu Integration
* 3D Model Import and Export
* Documentation
For details, see below.
—
Feature Ideas
Textures and Render Pipeline
I’d always wanted to implement textures for Prim.Blender. While this is trivial for sculpties, regular prims are a very different animal.
Now, Prim Composer already has texture support, so it wouldn’t be a huge leap to port that support to Prim.Blender. The devil is in the details, however; particularly, in mimicking the various display and render anomalies of the Second Life client.
Furthermore, I always came back to wanting to be able to bake robust materials from Blender straight to the prim surface. This is plausible and indeed, not terribly difficult, but would require constant monitor of Blender’s features and development path for the script API.
Effectively, texture support is a job in itself.
—
New Sculpty Sizes
Back in version 1.22 of the Second Life client, Qarl added the ability to create “non-square” sculpties to Second Life. By this, the dimensions of the sculpty map would define the number of faces used.
Prim.Blender has support for this at the backend already, as I’d effectively forked Domino Marama’s code.* However, certain improvements and testing are required on Domino’s code to prevent the functions from crashing.
—
Primitive Animation Sequences
Back in March of 2005, I drafted an animation system for prims. The basic idea was to use regular prims to play various BVH animations, as a means for vehicles, visual effects, and autonomous avatars.
Being able to specify the animation of prims using Blender motion data would be a logical extension of this project. The trick would be programming such a system fluidly, accounting for the speed that Second Life renders motion data (ie, llSetPos and llMoveToTarget).
—
Sculpty Animation Sequences
Similarly, being able to bake in visual effects to sculpties would be a win for Blender users.
Domino’s tools already allow for this, provided one has significant knowledge of Blender’s vertex animation and baking systems. As the aim of Prim.Blender is to make these tools more accessible, being able to build animation sequence data into a series of sculpty maps automatically would be a significant step forward.
—
Light Render Tests
With the new changes to the lighting system to enable real-time shadows and dynamic lighting effects (AKA, deferred lighting), it would be a big win to have Blender lights translate to Second Life.
Once again, an eye for nuance would be required, along with working very closely with the Render Pipeline client as it develops.
—
Texture Projections
Another new feature of the render pipeline build is the ability to project textures onto another surface.
This is technically possible in Blender, and would be very useful for testing effects prior to committing them in Second Life.
—
LSL and Link Impostering
Several of the best texture and render effects are done through the use of LSL scripts, including some of what’s listed above. Being able to imposter the particle system, linking system, and various scripted effects would be very helpful to tweaking models and textures in Blender.
While technically part of the XML prims specification included with this project, script contents add a whole new dimension to working with this tool. Specifically, they would allow developers to test their builds and sandbox new ideas outside of Second Life.
A possible implementation of this would be to migrate some of libSL’s code into this tool. However, such a project is a major undertaking. The farthest I got was the initial scope and skeletal implementation.
—
Bug Fixes
Refactored Mirror Support
Prim.Blender currently mirrors sculpties along all three channels: Red (X), Green (Y), and Blue (Z). As implemented by Qarl, Second Life now handles the mirroring and inversion of sculpties on the fly, but in the case of mirroring, only along the X-axis.
Effectively, the refactored code would be nothing more than two bits to specify mirror and invert, just like the current sculpty spec. Normals would need to be flipped appropriately, and mirroring functions handled accordingly.
The basis of this change would be purely to save on textures when uploading to Second Life.
—
Fixes to Primitive Params
As pointed out by several residents, various changes to the client code have caused a bit of drift between my own functionality and that of the Second Life viewer. In addition, several bugs in my own primitive params exist, particularly on coverting certain values and with the size of spheres.
Ideally, such work would be paired with refactoring the primitive code itself, as it’s currently a bit of a mess. See “Code Refactoring” below for more details.
—
Prim Torture
My tools have always assumed no support for prim torture. In light of sculpties and very small prims, however, this assumption would to well to be revised, for residents that continue to make use of these features.
—
Megaprims
Currently, Prim.Blender does not support megaprims. However, this support would be trivial to implement, given a list of fundamental megaprim sizes, and the ability to include them with copies of the importer.
Personally, I have mixed feelings on revising the code to support megaprims, since they’re not an explicitly supported feature by Linden Lab. However, residents have proven the usefulness and desire to create efficient builds using them, and I’m not one to argue.
—
UI Cleanup
The UI code for Prim.Blender is a bit of a mess. In addition to minor quirks and timing issues, the current assumption of using a timer instead of an event for primitive updates should be revised. This was originally implemented for (now) very old Blender API support.
—
Benchmarking and Expanded Use Cases
Several residents have reported various problems using Prim.Blender with functions of Blender, including Ctrl-Z (Undo), texture and object manipulations, and combining with other scripts.
Expanded use case scenarios, tests (see below), and work with the Blender interface itself would fix a lot of these issues.
—
Code Refactoring
The entire code tree needs refactoring. When I originally envisioned Prim.Blender, I designed it as monolithic code written in much the same way as a book. Given my programming experience has dramatically improved over the years, I realize the need to convert the entire code tree into a more modular, flexible structure than that which currently exists.
Specifically, every direct function should live in its own logical file, original assumptions should be documented in the code tree and tested against at the function level, and the entire tree should be refactored to reflect current assumptions of both the Linden code tree and quality.
In particular, this project was written before the client source was available to residents. Ideally, this code would use the same documentation standards and structure as the client tree, and quite possibly be merged into a section of it.
—
Dev Tests and Errata
More Thorough Regression Tests
The regression tests for Prim.Blender are very, very weak at the time of this writing. In order to ensure robust code, the entire tree MUST be tested rigorously at the unit, module, and integration level, and tested again with every version regressions.
Currently, my tests are generally topical, at the integration level. Tests should be interleaved within the code tree, allowing for easy testing and verification.
—
Menu Integration
Prim.Blender currently exists as its own menu system, residing in the script window of Blender. In addition to relying heavily on this system not crashing, the system should rely more on Blender’s own import and export logic than its own duplicated “Save” functionality.
Effectively, the “Save” button should become an export to prims, “Load” to import, and the user should expect to just save the .blend file for the entire set.
Much of this currently works in the public build, but has not been thoroughly tested.
—
3D Model Import and Export
Over the past few months, I’ve worked with various ideas on how to convert an entire Blender scene into a set of sculpted prims. In addition, this method would work to “combine” multiple primitives together into a single, sculpted unit.
All one would need to do is compute the outer edges of a multi-primmed or mesh solid. Next, sculpties should be applied to the surface area of the model as a series of “patches”, following the loops of the solid until all faces are accounted for.
Essentially, this method uses sculpties to “patch” a model together. While issues regarding seams exist, this would allow one to import 3D models directly from Blender into Second Life, complete with textures and baked material properties.
Another option would be to simply have a sculpted prim “conform” to the surface of a mesh solid or prim set. Such a system would be very good for “impostering” a series of models in very few prims, but would take a severe hit to detail.
—
Documentation
The final prong of this project that I never managed to get to is robust documentation. Domino Marama and Gaia Clary have done a terrific job of documenting their own sculpty system using video tutorials, written documentation, and multiple help threads on the forums.
My own project somewhat pales to this work, in that it’s been a sole labor of love by one person. Future maintainers should take a stab at thoroughly documenting this project at the technical, user, and tutorial levels.
I will admit some jealousy, in the hard work Gaia put into documenting Domino’s tools. But such is the way these projects work out.
—
Thanks for reading. I hope this documentation serves to help future developers work with my tool, and develop future external tools for Second Life.
* I’ve edited Domino’s tools to upload non-square sculpties right out of the gates, and refactored a bit of the code. Should anyone be interested in this revised build, please let me know in comments or by email (tom plus the domain of this page).
Entries (RSS)