http://halfpastnull.com > Division by Zero. Singularity terminated. Fri, 20 Nov 2009 05:56:08 +0000 http://wordpress.org/?v=2.9.1 en hourly 1 http://halfpastnull.com/index.php/2009/11/20/hiatus/ http://halfpastnull.com/index.php/2009/11/20/hiatus/#comments Fri, 20 Nov 2009 05:54:22 +0000 MrGomez http://halfpastnull.com/?p=286 It’s been fun! But for now, I’m closing this blog.

Second Life has been a terrific muse. While I still take part every so often, I find I no longer have the initiative or time to develop my tools further. I feel others have done a more than adequate job of taking my place. To them, I am thankful.


Because this blog was always dedicated to my works in Second Life, this hiatus represents one of two things: either a closure, or a change in focus to my other interests.

I am still very passionate about 3D and virtual worlds, and continue to express that passion elsewhere. But I feel my time with the Linden system is at an end.


To those who listened to me ramble all these years, thanks! I wouldn’t have come this far, nor created what I had without your time and support.

The pages I’ve posted here will remain active, as well as my contact information and source code. I simply won’t be posting about Second Life any further.


One chapter ends; another begins. Here’s hoping we meet again in the not too distant future. ]]> http://halfpastnull.com/index.php/2009/11/20/hiatus/feed/ 0 http://halfpastnull.com/index.php/2009/05/14/on-interactive-fiction-and-the-narrative-quality-of-second-life/ http://halfpastnull.com/index.php/2009/05/14/on-interactive-fiction-and-the-narrative-quality-of-second-life/#comments Thu, 14 May 2009 10:51:32 +0000 MrGomez http://halfpastnull.com/?p=158 interactive fiction. Don’t panic; this addiction is entirely benign, and shouldn’t impact our regularly-scheduled posts on Second Life.

(However, other factors have impacted this a bit. More hopefully in the coming months. – Ed)



(Image via Usonian’s Flickr stream)


It may come as a shock to readers here, but in an age of increasing emphasis on visuals and 3D graphics, I feel we still have much to learn from the acetic forebears of MUDs, MOOs, and others. As true to its roots as its ever been, the IF genre has much to offer to creators in Second Life.


But don’t just take my word for it. Keep reading.


—

My main intrigue in IF is, in base form, twofold.


First, proponents of IF place emphasis on narrative quality, given this is the defining characteristic of the medium. Second, IF titles attempt to tackle the reason we play and enjoy the medium. These are qualities that Second Life sorely lacks.

With cards firmly on the table, let me elaborate.


In IF, through proper narration and character modeling (in a literary sense), the player is always kept on track and apprised of the goal at hand. Goals are either slowly revealed to the player, or bluntly driven in with every step. Puzzles are solved by logic, or more commonly, through the use of picking up and using everything that’s not bolted down.

True masters go a step further. Masters don’t just lead the player; they actively engage them. Instead of simply leading the reader by the hand, pros weave them into the story. Instead of a linear adventure, paths diverge without detracting from the story. And throughout, the player is told to constantly push further, explore, and experiment.



(Image via Flickr user nonXpert (group link))


Of course, successful engagement of the player is best served with a side of intrigue and hook, plot or otherwise. The best venues for engagement in IF appear to be humor (Augmented Fourth), deep writing and characters (Make It Good), or unique settings and gameplay (Inside Woman, All Things Devours). This is loosely verified based on comments on raif/rgif, various contest postings, and my own experiences playing through these titles. Before you ask, yes, this is all accomplished completely in text.

Perhaps overarching throughout, many IF games also attempt to tackle the reasons for writing, playing, and occasionally, seek out existential questions. This should come as no surprise, given the IF genre’s roots in writing and novelist perfection.


Moving back to our original topic for this blog, this sort of engagement is sorely lacking in Second Life.

Given the impetus to create and sell works in a purely abstract sense, many creators seem to have forgotten the point of what it is they’re creating. While there are many corner shops and vendors, there are very few worlds to explore, which has led Second Life to take on more of a frivolous quality than that originally intended or envisioned. I suspect prohibitively high costs are a factor in this, as is the vast commercialization of the product.


In my time in Second Life, I’ve spent time working with club owners, sim owners, RPG makers, and projects spanning from Dark Life to the Isle of Wyrms. In all of these cases, the visuals and social aspects hold a premium. Often, the emphasis is commercialization first (to recover costs), visuals and community second, and narrative quality or rich experience as dead last.

Very few of these areas offer what could be considered a true “path” for new players or intrigue for residents. This leads to one of Second Life’s defining characteristics: a constant disjointed feeling of wanderlust, to which many people simply cannot relate.

There have been exceptions to this. Several recent projects in Second Life have attempted to create niche products, using the world as a platform. This has had some mixed success; very few applications lend themselves to a rich 3D or visual experience, beyond the confines of gimmicks and marketing. Visual education, arts projects, simulated sciences, and architecture have flourished, though there is much ground left to cover.

From the hobbyist perspective, Numbakulla ranked highly on this list for richness of experience and narrative quality. Unique to projects like Numbakulla (and before it, various shades of adventure and Myst spinoffs), one could experience a true mystery to solve and richness of narrative that one does not normally experience in Second Life.

This was quickly noticed, and indeed, the Pot Healer adventure enjoyed fair popularity by Second Life standards. However, given the high costs of maintaining the sim over time, this build has changed hands several times. Many other projects of this nature have simply folded, by either failing to retain interest, or through gradual conversion into a commercial product nothing like the original.



(Image via Liqueur Felix’s Flickr stream)


Before I continue, it may seem that I dislike the commercial aspects of Second Life. This is flatly untrue. Indeed, Second Life could not survive without its strong, real world currency system and virtual economy that has inspired so many newer writers and artists to ply their trade with the medium.

However, I feel that the stark commercialization at expense of all else limits Second Life’s abilities as a platform.

The strongest aspect of this is its incentives. The cost of owning appreciable land in Second Life is prohibitively high, to the order of several hundred dollars USD a month to own just one sim. The primary message to residents has, since at least 2006, been commercial in nature.

Why, then, should anyone attempt to create their dreams when they’re working hard to maintain their land payments?



(Image via Lif…’s Flickr stream)


This all strays significantly from the original topic. My attempt is not to rag on Second Life or IF — merely to point out what each medium lacks, such that we may improve upon them both. And ultimately, the continued survival of IF and Second Life both hinge on incentives, intrigue, and balance.

For IF, artistic pursuits lend themselves to very compelling worlds that are difficult to market and sell.

For Second Life, commercial maximism has created an experience that is slowly rotting itself without intrigue.

As someone deeply interested in the former and the latter, it would be interesting to see Second Life regain the pioneer spirit that drove many of us to use it in the first place. For IF, I wish only that authors can retain their drive to create and innovate within the medium, despite difficulties marketing and selling IF stories.


And in both cases, the best we can hope for is balance.]]> http://halfpastnull.com/index.php/2009/05/14/on-interactive-fiction-and-the-narrative-quality-of-second-life/feed/ 0 http://halfpastnull.com/index.php/2009/05/07/roadmap-from-the-cutting-room-floor/ http://halfpastnull.com/index.php/2009/05/07/roadmap-from-the-cutting-room-floor/#comments Thu, 07 May 2009 05:05:26 +0000 MrGomez http://halfpastnull.com/?p=150

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).]]> http://halfpastnull.com/index.php/2009/05/07/roadmap-from-the-cutting-room-floor/feed/ 0 http://halfpastnull.com/index.php/2009/04/20/restart/ http://halfpastnull.com/index.php/2009/04/20/restart/#comments Mon, 20 Apr 2009 20:05:19 +0000 MrGomez http://halfpastnull.com/?p=146
Prim.Blender is effectively without a master at the time of this writing. Shack Dougall has done a terrific job over on LifeRain working on Prim Composer, and floating the idea of porting it to Blender. If you support continued offline development, his work is excellent, and worth pursuing.


As for my own development status, here’s a few tidbits I’m working on that I’d like to share.


—

After musing with job ops and my old career in antivirus, I’ve come to the conclusion that Second Life is actually a Good Thing (TM). That is to say, the emphasis now is necessarily more on the community than it is the technology backing it. This has interesting ramifications that I’ll discuss at length in future postings, modulo interest in how that all works.


As for myself, well…

First off, I’ve gone freelance. That means you can get a slice of my time for your own projects. If you’re looking for a good programmer or scripter, shoot me an IM (Jeffrey Gomez) or email (tom [-at-] halfpastnull [-dot-] com). I’d be glad to help, but I need to eat too.


Second, I’m currently working on a few odd avatar and scripting projects in Second Life. If you have insight into cool projects you’d like to see built, drop me a line and we’ll discuss how to make those a reality. More often than not, I have insight on how projects like those have been made in the past, and how to make them work today. I’m interested in ideas up to full sim jobs, if that’s what you have in mind.

Finally, on the repurposing of this blog: I’m shifting it over from just straight tutorials and evangelism to cool things I find in my travels of virtual worlds. That’s a pretty broad spectrum, going all the way from text adventures (!) to high technology and the so-called “metaverse” populated by apps like Second Life. I expect it all to be fun, and hope you folks share in my enjoyment.


Anyway, that’s it for now. Send me feedback! After all, it’s what keeps me writing and working with Second Life. ]]> http://halfpastnull.com/index.php/2009/04/20/restart/feed/ 0 http://halfpastnull.com/index.php/2009/01/21/about-primblender-and-the-state-of-this-blog/ http://halfpastnull.com/index.php/2009/01/21/about-primblender-and-the-state-of-this-blog/#comments Wed, 21 Jan 2009 07:50:56 +0000 MrGomez http://halfpastnull.com/?p=130
Newcomers to this site may notice I haven’t posted new material in the past six months. A large part of this was the completion of my Master’s degree at the University of Miami. But… some of it wasn’t.

In particular, I want to discuss the lapsing of support for Prim.Blender, what it means, and what I have next on my own agenda.



Before I continue, I want to let everyone know that it’s been fun. Really. You all have been great at keeping your questions civil, interesting, and to the point when contacting me, and I really appreciate it. Just as I hope you learned something from me, so too did I from all of you.


It’s truly been a great three and a half years. But all good things must come to an end, should they remain “good things” for all involved.

—

Several of you have asked me what exactly it means to be “lapsing support to other tools.” This means:

* I will continue to answer support email and forum questions addressed to me.
* I will no longer be working on Texture support for the tool, nor support updates to the Sculpty system by Qarl.
* I won’t be supporting porting Prim.Blender to third party grids at this time.
* I will begin referring people to other tools maintained by other residents, such as the fantastic Prim Composer by Shack Dougall and entries on this list.
* Anyone interested in continuing to maintain the project is more than welcome to step up and email me about picking up where I’ve left off.


As for the reason why I’m choosing to do all this, I find that I no longer have the time or the will to continue supporting this tool for Blender. This is due, among other things, to repurposing my time on other projects.

Over the years, Linden Lab and I have also differed on a series of core beliefs on what constitutes the so-called “Metaverse”; that’s part of it too, I suppose. And, while I am thankful to them for continuing to open source their system, I can’t help but feel we all could improve on their system in forming a true “standard” for how we conduct ourselves and our avatars.


For those interested in the continued hosting of Prim.Blender’s files and this site, don’t worry. I will continue to maintain the SourceForge page until a suitable replacement is made, and [re]purpose this blog to discuss more of my own personal and professional projects. I still do cool stuff these days, including within SL.


But more importantly, I’d love to know what you all think on this. This site doesn’t capture too much traffic at the time of this writing, but if you’re reading this, consider dropping me a line sometime.


What are your experiences with my tools? Were they useful? And what cool things have you done with them that you feel are interesting? I’d love to hear them.


Thanks for sticking with me through this journey. It’s been fun!

– Tom “MrGomez” Robinson

]]> http://halfpastnull.com/index.php/2009/01/21/about-primblender-and-the-state-of-this-blog/feed/ 1 http://halfpastnull.com/index.php/2008/07/22/primblender-setting-importer-permissions-and-creator-tags/ http://halfpastnull.com/index.php/2008/07/22/primblender-setting-importer-permissions-and-creator-tags/#comments Tue, 22 Jul 2008 05:44:11 +0000 MrGomez http://halfpastnull.com/?p=97 Prim.Blender. For the tutorial index, click here)

—-

Setting Importer Permissions and Creator Tags


From the previous tutorial, you should have been able to import your creations from Prim.Blender.

Normally, this would be the natural end of these tutorials.

However, and perhaps irritatingly, there is a step that’s very commonly overlooked when importing objects: setting the correct permissions and creator tag for imported objects.



This is a critical step for creators that wish to receive credit for their work, and is very often overlooked when using resident building tools.

Using old revisions of the Prim Mirror as an example, I receive at least one comment every couple months attributing work that was not mine to me, because a resident used my tools and forgot to set themselves as creator.

Don’t make this mistake.



—-

The easiest way to set permissions on your object is to link a prim that you created as the last [selected] in the set, then set permissions as normal.

However, any prims created with the tool via Select Linked Parts will still be visible as “Creator: Jeffrey Gomez”.

Furthermore, you will need to do this every time you import, which can be quite an undertaking.

Fortunately, there are more permanent ways to set this.

—-

Here’s how to set up the tool to use your own custom permissions and correct creator tag.

Start with the image presented at the top of this post:



Select “Child Prim” as pictured, and drag this out into the world:



Copy the script within this object to your inventory.

Also note the permissions and name of the object:



Now create a new prim.

Be sure to name this “Child Prim”, exactly as the object you’re about to replace.

You may also set your own custom permissions in this same window.



Now drag the script you copied from inventory to the new prim you created.



And once you’re done, delete the old Child Prim from the importer’s inventory and replace it with the one you just created.



That’s it! Now be sure to save this new importer to your inventory.

Using it, you’ll properly receive credit for your work with permissions you specify.

(And, you’ll be saving me the work of telling countless people to do the same!)

—-

Care to head back to the tutorial index?]]> http://halfpastnull.com/index.php/2008/07/22/primblender-setting-importer-permissions-and-creator-tags/feed/ 0 http://halfpastnull.com/index.php/2008/07/22/primblender-internal-blender-scene-saving-and-loading/ http://halfpastnull.com/index.php/2008/07/22/primblender-internal-blender-scene-saving-and-loading/#comments Tue, 22 Jul 2008 04:57:24 +0000 MrGomez http://halfpastnull.com/?p=80 Prim.Blender. For the tutorial index, click here)

—-

Saving and Loading Blender Scenes with Prim.Blender

So let’s suppose you have a lot of work invested within Blender itself, and can’t save all of it as .prims.

Or, let’s say you don’t feel like hitting the “Save” or “Load” buttons twice every time you want to work.

Enter the ability to save your work as a .blend file!



Actually, this is much easier than one might think.



—-

All you have to do is exit Prim.Blender via the Exit widget, then save normally.

Don’t know how to “save normally?” Simply select File > Save from the upper-left hand File menu, or press Ctrl-W and accept the given prompt.

Technically, this can be done while Prim.Blender is still running.

However, it is strongly recommended that you exit first, as this will prevent unforeseen errors from occurring, and supports far more Blender versions.

—-

That’s it! When you load this .blend file again, all your work will be there.

All you have to do then is execute the script again after loading, as explained in the basic usage tutorial.

—-

Care to head back to the tutorial index?]]> http://halfpastnull.com/index.php/2008/07/22/primblender-internal-blender-scene-saving-and-loading/feed/ 0 http://halfpastnull.com/index.php/2008/07/18/primblender-textures/ http://halfpastnull.com/index.php/2008/07/18/primblender-textures/#comments Fri, 18 Jul 2008 00:04:20 +0000 MrGomez http://halfpastnull.com/?p=55 Prim.Blender. For the tutorial index, click here)

—-

Textures

From the previous tutorial, you should now have a decent grasp of how Prim.Blender functions.

This tutorial shall cover texturing. It’s not done yet (because texturing still requires a ton of testing), so please be patient.



The ideal workflow is to do texturing entirely within Blender and then “bake” the desired image for import into Second Life.

In practice, this must be done manually in Blender, due to the myriad texturing techniques available. Many of these are covered in Blender’s wonderful tutorials and documentation.

Once your textures are set up just the way you like them, you can save the scene as a .blend file, preserving all of this information for later retrieval.



—-

Sorry to disappoint, but the remainder of this article is currently a stub.

Have ideas for texturing support? Email them to me!

—-

Care to head back to the tutorial index?]]> http://halfpastnull.com/index.php/2008/07/18/primblender-textures/feed/ 2 http://halfpastnull.com/index.php/2008/07/15/primblender-importing/ http://halfpastnull.com/index.php/2008/07/15/primblender-importing/#comments Tue, 15 Jul 2008 23:04:02 +0000 MrGomez http://halfpastnull.com/?p=27 Prim.Blender. For the tutorial index, click here)

—-

Once the build’s done, it’s time to import your creation into Second Life!



Most of the work is completely automated, especially for sculpties.



—-

To begin, you must first obtain the latest build of Prim.Blender.Importer.

Unless you’re a geek with time to compile things by hand, you’ll want to pick up a copy from my store:



Buy a copy of the importer for L$1:



Find a good place to set it out and enter edit mode:



Now alt-tab or mouse out of Second Life. Open your .prims file in a text editor.

If necessary, rename the file “.txt”, all you Windows users.



Don’t worry if the output appears slightly jumbled up; it’ll format just fine in Second Life.



Up until version 0.5.4, Prim.Blender saves linebreaks as “\n”, or UNIX mode. This has been altered to DOS Mode “\r\n” in subsequent releases, making output format properly in Windows Notepad.

Both format in SL just fine, regardless.



Save the output you just copied to a notecard. Name it whatever you like.



If any sculpties are present, you’ll also need to bulk upload the sculpt maps.



Be warned: this operation costs L$10 per upload. Unfortunately, there’s no avoiding this currently.



Now, shift-select all of the images you just uploaded and drag them from inventory to the importer:



And finally, drag and drop the notecard you saved to the importer.

If everything went as expected, you should see these messages, and when the process completes, “Done.”



Be warned that if you see warnings about missing images, you probably skipped the image step above.

—-

If everything went as expected, congratulations! Your prims should now be imported:





As a follow-up, you should set the correct permissions and creator information for your imported objects, or the importer itself.

You can do this by linking a prim you created as the last in the set, or altering your importer through this tutorial.

—-

Of course, if things didn’t go as expected, you can always poke me by email and ask me what went wrong

If things went well, be sure to tell me about it, too. I’m always interested in new builds.

—-

Care to head back to the tutorial index?]]> http://halfpastnull.com/index.php/2008/07/15/primblender-importing/feed/ 3 http://halfpastnull.com/index.php/2008/07/15/primblender-sculpties/ http://halfpastnull.com/index.php/2008/07/15/primblender-sculpties/#comments Tue, 15 Jul 2008 22:07:37 +0000 MrGomez http://halfpastnull.com/?p=24 Prim.Blender. For the tutorial index, click here)

—-

Sculpty editing is more than a little weird.

A sculpty, or sculpted prim, is the brainchild of Qarl Linden, though the practice he uses has been suggested before.

Think of sculpties as elaborate origami; you’re given a surface with 32×32 faces to fold into any shape you please. These “folds” are then saved as an image file, where each color’s RGB data represents a direction: red for X, green for Y, and blue for Z.



If I just lost you, don’t worry: making them is easy with the right tools.

Such as, say, this one!



—-

Sculpties are a relatively new addition to Prim.Blender, after nearly three years of builds (!). I have, however, strived to make working with them as painless as possible.

Sculpties in Blender are tied directly to mesh editing and Blender’s “sculpt” mode. The basic idea is to grab and manipulate the surface of the sculpted prim, then save (bake) it as an image file for use in SL.

Just so we cover everything, Edit Mode looks something like this:



And Sculpt Mode looks something like this:



Yoink!



Most of the tools are fairly self-explanatory: right-click a few verts in edit mode and move them around (G Key + mouse), rotate them (R Key + mouse), or scale them (S Key + Mouse).

Or, go into Sculpt Mode and use the Sculpt button (left of circled) and Blender’s fine sculpting tutorials to create most shapes you can imagine.

—-

From the interface pictured way at the top, you’ll see all of the standard UI components seen in SL. However, you will also see a bunch of foreign buttons that might not make a whole lot of sense at first glance:



For starters, what the heck are these buttons?

Number of Wrapped Faces? Multires? Sculpt type? There aren’t such things in SL’s sculpties, are there?

Actually, Qarl’s implementation of sculpties supports all of these things in one capacity or another. It’ll become more clear after a bit more exposition:

• Number of Wrapped Faces: Describes the minimum number of faces to use for this sculpty, in the X and the Y direction. Because sculpties are elaborate origami, this describes the number of creases you can create in each direction before fancy tricks like Multires (explained below).


• Multires: Adds additional levels of detail to this sculpty, in addition to the values described above. This is tied directly to the level of detail slider, and lets you inspect what Second Life™ will do to your sculpty when viewed at varying detail levels.


• Sculpt Type: A bit of smoke and mirrors that is hidden away from the in-world tools. Sculpties may be created in four different ways: with no merged edges (plane), one merged edge on the top (torus) or the side (cylinder), or two merged corners (sphere). In addition to these options, several different shapes may be created from the “base” type.

If this is all gibberish to you, don’t worry: the defaults and randomly pressing buttons works well enough for most purposes.

The only important thing to remember is the highest available level of detail will be the one used when creating the sculpty map. To avoid unexpected results, make sure to inspect your sculpty at this setting before baking (hint: it’s the Level of Detail slider).

—-

Now that we have those covered, how about those other buttons just below the sculpty image?



Those, at least, are a bit easier to explain:

• Bake: Lets you bake the sculpt map for this prim. This lets you inspect and manually save the map, if you’re into that kind of thing. This is done automatically when you save, for all sculpties.


• Load Texture: Lets you load a sculpt map as a texture. Should not be confused with the texture attributes of this prim. (Note: In future revisions, this has been renamed “Load Sculpty”)

Neither of these options should ever be required, unless you’re working with other tools (like Domino’s), or just happen to want extra control over your sculpties.

However, in releases at or beyond Prim.Blender 0.6.0, you may use sculpty loading to load a series of default shapes, found in the PrefMaps folder of each release.

These shapes are given by type: tsph for sphere, tcyl for cylinder, ttor for torus, and tpla for plane, and are included as starting points for various advanced shapes.

—-

That covers the basic explanation. Hardcore sculpty geeks can stay for all the details; everyone else should move on to texturing or importing.

—-

Caveats

• Face values are limited to powers of two, from 4 through 32. This is done to make building as seamless as possible, and prevent any “weird” texturing or multires errors.


• Values that do not add up to 32 faces on a side (the number of faces in a sculpty) will follow the shape of the current faces.


• Multires is capped at +2 levels, because this should be way more than is sufficient for testing level of detail changes in the SL viewer.


• Multires only works in Blender 2.46+; all other versions allow the slider, but ignore its value.


• Multires is turned off at a value of 0, for purists that just want a sculpt map to mess with.


• At the time of this writing, sculpties that are copied are treated as separate, instead of sharing the same image file (as in Domino’s implementation). If enough demand for this feature is present (email me or comment here), I may add the ability to create “groups” that share the same map.


• A “sculpty library” of shapes has been added to releases of Prim.Blender 0.6.x and above. If you have ideas or suggestions for shapes to add to this library, email them to me and I’ll offer full credit.


• The sculpty code in Prim.Blender is originally based on Domino Marama’s scripts, but may deviate significantly from his design, as my version represents a fork (or perhaps a spork) of his code. Furthermore, he and I exist within two very different paradigms for building with Blender.


• Sculpty image sizes in Prim.Blender should always be 64×64. This is the rough minimum for retaining full sculpty detail, while being entirely usable in paint programs, and addressing certain averaging and compression bugs.


• The “pixelated” effect exhibited by baking is intentional. This is the “compressible image” fix, first suggested by Aminom Marvin and implemented by Domino Marama. It is also used in mirroring.


• All images are automatically saved as .tga. Sorry. Blender is anal about that, currently.


• Duplicate images (ie, sculpties that are *exactly* the same) will be culled. This results in far fewer texture files to upload, making the process cost a whole lot less.


• Occasionally, Blender will save images as Targa files that aren’t 24 bit. This will be noticed during bulk uploading. In these cases, please manually save the file as a different type, or change its pixel depth to the correct value.

—-

If you have suggestions regarding my design or documentation, please email me.]]> http://halfpastnull.com/index.php/2008/07/15/primblender-sculpties/feed/ 0