Downloads and Support

Post edited 5:27 pm – May 30, 2009 by Shack Dougall

This thread is for discussing this poll:

Currently, Prim Composer takes a conservative approach to exporting prims and textures out of Second Life and OpenSim.

You can only export prims that you both created and own.  No textures are exported except sculptmaps that are on sculpties that you created and own.

The difficulty with textures is that Second Life makes it difficult to verify the creator/owner of a texture and in some cases, it is impossible to verify this information.

I am currently considering a compromise.

The new proposed behavior is for Prim Composer to allow you to export any texture that is on a prim that you created and own.

Note that this opens the possibility that textures will be exported that you didn't create.  It would still be your legal responsibility to verify that the owner of those textures has given you permission to export them.

So, what do you think? Please express your full thoughts, but be polite and cordial, please.

There is no perfect solution to this problem and the limitation that the prims have to have been created and owned by you is still a pretty strong test.  It does open up the possiblity of texture theft, but texture creators are already extremely vulnerable in the SL architecture.

Ultimately, the responsibility lies with the person doing the exporting.

Hello ,

I agree completely with TakuanDaikon.

MaxProxy will not be the first tool capable of getting other's people textures , but it will be the first one that checks prim creator/owner name. I don't think someone will blame you in any way.As a creator i vote for "Any textures that are on prims that you created and own."

Best regards and wishes

Big thanks to everyone for the comments, so far.

This is an important decision that  should include the whole Prim Composer community and it wouldn't hurt to get input from people who actually sell textures in SL.  I don't know any of them personally, but if you happen to know some of them, feel free to share a link to this thread.

Here are some of the issues that I'm thinking about.  This is a long post and I don't reach any conclusions.

Round-trip Workflow

Prim Composer must support a round-trip workflow.  We must be able to create a build in 3ds Max, texture it, upload it to SL or OpenSim, and then be able to make changes to it in SL/OpenSim and bring that modified creation back into 3ds Max.

This is not a simple problem and the proposal in this thread won't solve it in the general case.  In many cases, we wouldn't want to simply bring the baked texture back into 3ds Max.  Instead, we might want to merge changes that were made in SL/OpenSim with the original model in 3ds Max.

Backup/Transfer

Another thing that Prim Composer must support is a way to backup our creations.  If we create a build in 3ds Max, upload it to SL/OpenSim, and make changes to it in SL/OpenSim, then we need a way to backup the modified creation and also a way to move that modified creation to a different grid if desired.

The simple use case for transfer is that we upload our creation to a local instance of OpenSim to see how it looks.  Maybe there are some small changes that need to be made "in world".  Composite sculpties are an example.  They don't always get imported into the world perfectly.  The positions of individual sculpties in the composite might need to be tweaked.  Then, we want to upload that modified creation to Second Life.

The larger the scale of the project, i.e., the more prims in it, the greater the need for this kind of workflow.

Recent changes in Second Life that affect taking and rezzing large builds

I am also following a recent change  in Second Life (SVC-4207).  The initial implementation of this change was to limit the number of prims that you can take into inventory to 1000 prims.  This makes it impossible to backup large builds into inventory using the traditional select/take copy method.  It also makes it much harder to move a large build from one sim to another within Second Life.

This limit has recently been raised to 4000 prims, but it is still a very troubling development.

Moving and backing up large builds

But even without SVC-4207, large builds were difficult to manage.  Selecting and taking thousands of prims is not reliable in either Second Life or OpenSim.  OpenSim has the added problem that coalesced linksets cannot be taken into inventory as a single object.  In OpenSim, if you select 10 linksets and take them into inventory, then you will get 10 different objects in inventory rather than 1 coalesced object.  The only method I know in OpenSim is to create an OAR file.  I think this might backup an entire sim.  Not sure if it can be used on smaller increments and you probably have to be an admin on the sim.

SecondInventory

SecondInventory is a widely used tool to backup inventory and to transfer inventory between grids.  My understanding is that it will transfer all full-perm objects.

There are two issues of interest here.

1) is the fact that SecondInventory is currently less restrictive than Prim Composer would be with the proposed change.  Prim Composer would still require that the object be created/owned by you.  SecondInventory only requires that the object is full-perm.

2) SecondInventory only backs up inventory.  You must be able to get the object into inventory before you can back it up.  Given SVC-4207 and the other problems associated with large builds, this is impossible for many builds with large prim counts.

Pre-existing builds

Pre-existing builds are builds that were created without the use of Prim Composer.  A big question is whether or not Prim Composer needs to support these and to what degree.  Currently, you can export any pre-existing builds that you created and own.  All sculptmaps and prim data is exported but no textures.

Because of SVC-4207, there is currently no easy way to backup a large build in SL.  You can't take copy a large build into inventory. SecondInventory won't help because you have to take it into inventory first.  CopyBot is the only current option that I'm aware of.  This is intolerable.

More than anything else, this is what is motivating me to make this change in Prim Composer.

There must be an easy, reliable way to backup and move large builds within Second Life.

Backup vs Intra-Grid Moving vs Inter-Grid Transfer

There are at least three different things that you might want to do to a pre-existing build.

1) Back it up, so that if something happens to the assets in Second Life, you can restore it.

2) Move it to a different place within the same grid.  Note: this is different from backing up because the assets are known to exist.  You wouldn't need to download textures to move a build to a different sim in the same grid. 

Practically, however, it amounts to the same thing.  If maxproxy were to export the texture keys, but not the textures themselves, then you could just turn around and run maxport on the file with –export-textures and it would download the textures.

3) Inter-grid transfer.

Conclusion

I don't really have one yet.  I'll post some more when I've digested what I just said.

Post edited 3:36 pm – Jun 1, 2009 by TakuanDaikon

Shack Dougall said:

Post edited 2:44 pm – Jun 1, 2009 by Shack Dougall

---

I was also thinking about full perm textures.  I think if a texture is full perm, then the SL viewer allows the user to save the texture to disk using the viewer.  If this is true then allowing Prim Composer to save full perm textures would simply be an automation of what is already supported in the official SL viewer.  I need to verify that I'm right about how that works.

I strongly believe that is correct.  But think again of round-trip workflow.  Right now PrimComposer generates functionally meaningless texture names (much to my dismay) and it's not always obvious by looking at the texture or it's filename which texture goes on which prim – at least in the case of sculpties.  That 'simply an automation of what is already supported' could be a major workflow enhancement, in some cases.

With my current build, I do some work in PrimComposer, import into OpenSim, and swap textures as needed.  I've been through at least a dozen iterations so far, and will certainly have a few more to come as I try to tweak the textures to perfection. 

When the time times to call it done and import it into SecondLife proper, it's going to be quite a chore determining which of the several hundred gobbledygook-named textures are the ones I've finally settled on.  I have a process that will make that doable, but it's by no means painless.

It's enough of a pain, in fact, that I've more than once considered writing my own version of MaxPort.  I've already made libopenmv custom exporters for legacy builds, so I'm somewhat familiar with how it could be done, but I'm desperately hoping that PrimComposer will obviate the need to do so before I get to that level of desperation

P.S.: PrimComposer's XML format is so much cleaner and better than the default LLSD crap that is the 'out of the box' export functionality.  Kudos on that.

.

Post edited 1:28 am – Jun 2, 2009 by TakuanDaikon

I don't have enough of a suggestion to justify a whole thread, I don't think.  When I was having trouble with PrimComposer's texture baking and wrote my own batch-baking script, I just had it name the textures with “[PrimName]-texture.[ext]” format. I did this because the textures were not specified in the export XML and therefore not automatically applied by MaxPort, so having meaningful names was a high priority.

Because Max does not enforce unique object names, it does a pre-render pass to ensure unique object names (by appending and incrementing counter when a duplicate is found).  In practice, it very rarely renames anything, so the result is that I can pretty much always tell by name alone which prim a texture belongs to, and when I cannot tell that way (say, because the prim is named Cylinder04) it's easy enough to Find the prim in Max.  You can't do that with PrimComposer-generated texture names, so even that is an improvement for me

I think we've already seen that you are better at coming up with the final design/solution/process than I am.  I just work in quick-and-dirty, man

.

Post edited 12:56 pm – Jun 2, 2009 by Shack Dougall

rodrigo2kx said:

i believe that all textures in prims (owned by you or not) should be downloaded by primcomposer.
Why? it's easy. Many ppl (like me) works in a builders group. Wich means that every user that it's in that builders group can modify my objects and change parameters, textures, etc.

if they think that they can improve my building by changing textures, they have my granted permissions to do it. and so on.

This is a good point and there are a couple of intermediate steps that might be taken.

For example, Maxproxy could be changed to work with objects that are deeded to a group and/or shared with a group.   In SL, sharing with group grants three permissions to people in the group (Modify, Copy, and Move).  Since copy is granted and the membership of a group can be restricted, it might make sense to allow prims/textures to be exported.  In addition, deeded objects can also be transferred, so it makes even more sense.

However, it probably should only be allowed on objects that are both created by a person in the group and owned by a person in the group (where the creator and the owner do not have to be the same).

Two problems with allowing this are that it would circumvent next owner permissions and it would allow the object to be re-imported with a different creator.

It isn't clear to me yet how big these two problems are.  I need to consider this in more detail.

I just became aware that the Meerkat Viewer allows you to export/import builds that you created.  See the video at the bottom of the Meerkat homepage to see a demonstration.

This is interesting on a couple points:

1. It seems to use the criteria that I proposed in this poll.  That is, if you created the object, then it exports the object along with any textures on the object.  (I need to verify exactly what the rules are)

2. This is potentially another importer/exporter that could be used with Prim Composer. 

However, it uses a different XML format (llsd), so I'll need to make some changes to make it work with Prim Composer.  Also, it saves the images only in jpeg2000 format, so they won't load in 3ds Max (I think) without some conversion.

But I could create a converter between the two formats.  And I could modify maxport to read/write the Meerkat format.

I'll try to get some kind of Meerkat workflow working in the next release (ticket).

Post edited 12:06 pm – Jun 25, 2009 by Shack Dougall

rodrigo2kx said:

Hi There Shack!. Are you planning to release a new maxport/primcomposer with these new features soon?. I ve been expecting it since you expose the whole idea. xD

Yes!

I've been busy with other things, but I'm about to come back to it.  Last week most of my time was spent working on the website.  It's built using WordPress and every time that a new version of WordPress comes out, I get sucked into a black hole of updating plugins and debugging everything that breaks as a result. 

My current thoughts on textures:

Prim Composer will export prims that you created and own (as it does today).  With regard to textures, it will look in the prim's inventory for the texture. 

• If it finds the texture in the prim's inventory, then it will check the permissions and only export the texture if it is full perm.
• If it doesn't find the texture in the prim's inventory, then it will assume that it was full perm and export it.

I'm not sure when the next version of Prim Composer will be released, but I'll try to put this in it.

The thought process behind this involves the following observations:

• The SL viewer allows you to save a full perm texture to disk.
• The SL viewer does not allow you to save a non full perm texture to disk.
• If a texture is not in a prim's inventory, then the texture was either full perm or it was set by UUID via LSL or through libopenmv.
• If it was full perm, then it seems reasonable to let Maxproxy export it because the SL viewer allows a person to export it.
• If a texture is in a prim's inventory and it is not full perm, then it seems wrong to export it, since the SL viewer would not let a person save it to disk.
• If it was set by UUID, then it is difficult or impossible to discover the permissions.  At a minimum, it would require searching the user's entire inventory which would be costly since many people have inventories with tens of thousands of items.  But even this wouldn't be sufficient because the texture could be inside of an object in the inventory, requiring us to search not only the inventory, but also the contents of every object in the inventory.  And even that would not guarantee that we can know the permissions because the texture could have been in the person's inventory when the prim was created and then subsequently deleted.

Opensim is currently considering expanding the creator info for objects to inclide more thatn one creator, in the case of collaborative builds, and fields for the creators of the textures used, anims used, scripts used, and a license field where info on these other assets (apart from the prims themselves) can be provided. This is only under discussion at the moment, but I shall report any definite decisions I hear about.

Incidently, although Maxproxy does not currently export any textures, does the Import function of Primcomposer work as far as importing textures are concerned, or does both need to be rewritten for texture use? I was thinking, that if the Import function is already complete, could the textures used in a build be placed in the textures folder that maxproxy creates so that when Imported all the textures are in place?

Rock

Post edited 4:48 pm – Jul 14, 2009 by Shack Dougall

TakuanDaikon said:

Post edited 1:28 am – Jun 2, 2009 by TakuanDaikon

---

I don't have enough of a suggestion to justify a whole thread, I don't think.  When I was having trouble with PrimComposer's texture baking and wrote my own batch-baking script, I just had it name the textures with “[PrimName]-texture.[ext]” format. I did this because the textures were not specified in the export XML and therefore not automatically applied by MaxPort, so having meaningful names was a high priority.

Takuan,

I did some thinking about the filenames that Prim Composer generates and how they can be made more human-friendly.

Prim Composer 1.3.2 (releases July 15th) changes the way that baked textures are generated.  They now have the prim name prepended to them.  That should help.

Looking at the larger problem, the biggest impediment are the cases where textures can be shared between prims.

For example,

• in 3ds Max, sculpties can be instanced and this results in one sculptmap being shared by multiple prims.  It's not clear how to name the sculptmap in a human readable way.
• exporting from Second Life or OpenSim, it is very possible for textures to be shared between prims.  Ideally, I could use the name of the texture to name the file, but Second Life only gives me the UUID and I would have to search the user's inventory to find the name.

I will continue to try to improve this, but in many cases the solution to the general case isn't straightforward.