Prefabs and Hierarchical Instancing discussion

[Zebrazilla]

I have created a draft on the wiki for a features idea regarding prefabs (see /wiki/Prefabs-and-Hiearchical-Instancing) and what I'd like to call hierarchical instancing. Any feedback on these ideas, any discussion and critique of how these could be improved, would be greatly appreciated. As such I am creating this issue and pasting the draft as it looks upon creation. Don't hesitate to reply to this issue if you have anything to say or make changes as you see fit to the wiki page.

Prefabs and Hierarchical Instancing

This page contains loose specifications on prefabs and hierarchical instancing; Herein you may find a summary of the purposed system and its practical purposes, criteria on what would be needed and thoughts on how it may be implemented. This is a draft and meant to initially pitch the idea.

Summary

The purpose of implementing prefabs and hierarchical instancing is to ease the creation of maps by artists and to make it degrees of magnitude more efficient. So what are prefabs and hierarchical instancing? What follows are short descriptions:

• [x] Prefabs are selections of world geometry (cubes) that are saved outside of the map, allowing these prefabs to be worked upon individually as well as imported into whichever map is desired, as many times as is desired.
• [ ] Instancing is a fancy way of describing importing and showing these prefabs in a map. Prefabs are instanced as models within a map, allowing the prefabbed geometry to be duplicated many times over while still retaining a source prefab which can be manipulated. Here lies the key feature and benefit to prefabs and hierarchical instancing, the ability to only have to change the original prefab and watch all instances of this change as it is saved.
• [ ] Hierarchical instancing is an even fancier way of describing instances of prefabs within prefabs. Essentially what this entails is that a prefab may be sub-divided hierarchically into several different structures and sub-structures.

To demonstrate the usage and effectiveness of hierarchical and the whole pipeline of working with prefabs and instaces of prefabs, please picture this:

1. Bob create a rudimentary prototype of a staircase with 10 steps and 2 railings in his new prototype map_a.
2. Once Bob is happy with his prototype he creates a prefab for this staircase.
3. Within this prefab Bob creates further prefabs:
4. 1 prefab for individual steps in the staircase and instancing this 10 times total for each step.
5. 1 prefab for the railing and instancing this 2 times total for each railing.
6. Underlying geometry to hold up the staircase that is part of the root prefab and not split into further prefabs. Bob now has what we can call a hierarchical prefab, with prefabs contained within his prefab.
7. Bob begins to create instances of this staircase to fill out prototype map_a.
8. Bob is now happy with his prototype of map_a and sendmap to his friends for testing of gameplay flow.
9. While Bob awaits feedback he begins prototype of map_b which will feature the same art style, again Bob makes instances of his trusty staircase prefab to fill out map_b.
10. Bobs' friends have now tested map_a and it's time for Bob to flesh out map_a with detail. Bob loads up his staircase prefab and begins to work on details.
11. Once Bob is happy with how his 1 step prefab looks he saves it. Now all instances of this staircase in both map_a and map_b are changed.
12. Happy with his new-found efficiency he finishes detailing on the 1 railing prefab as well as the underlying geometry in the root prefab. Saving these Bob now finds that both map_a and map_b have beautiful staircases. To think that all he had to do was change one prefab and the prefabs contained within it's hierarchical structure! Bob is real happy now.
13. But wait. Along comes Alice who works on gameplay mechanics. She informs Bob that the step height in the physics code for player movement has suddenly changed and that players in progress of testing his map can no longer walk up his beautiful stairs! The horror! But wait again, Bob has his trusty hierarchical prefab.
14. All Bob has to do is go into his step prefab contained within the hierarchical structure of his staircase prefab. Bob makes the change, saves the prefab and commits the one prefab to be available. Doing this with time to spare, Alice and all the testers rejoice in being able to continue testing all the things! All the while Bob in no time is back to doing what he does best; Making prefabs within prefabs within prefabs!

    Proposed Functionality

While there are many ways to accomplish prefabs and hierarchical instancing, one potentially useful way to tackle this is to have prefabs effectively be models within maps, while prefabs actually being world geomatry saved in their own .ogz containers/maps.

Below follows some brief thoughts on how prefabs and instancing may be accomplished and the functionality of different steps needed:

• Exporting and saving selection of world geometry into separate .ogz containers/maps (read prefabs).
• Importing, rendering and positioning geometry from a prefab as a model within a map.
• Convert an instance of prefab model geometry back into world geometry while still inside a map (toggle by command?).
• Allow editing of prefab model geometry as world geometry and saving back to the prefab when done (assisted by above feature).
• Unlinking an instance entirely from its prefab, creating standard world geometry out of all of the content in the prefab and its possible sub-prefabs.

Possibly useful resources:

• Tesseract prefabs

[IAmNotHanni]

+1 We need all this functionality wrapped in a smooth user interface in CEF.

[Croydon]

Prefabs are implemented in the meantime.

However, why a) is /saveprefab destroying the lighting? There shouldn't be any geometry updates. b) are prefabs not available in multiplayer?

//cc: @Zebrazilla

[basile-henry]

Prefabs have been done by @lsalzman, I can look into fixing the lighting on a save. I believe the issue is because it's invalidating the lighting after using blockcopy. In saveprefab:

if(b->copy) freeblock(b->copy);
protectsel(b->copy = blockcopy(block3(sel), sel.grid));
changed(sel);

I'm not sure what the point of "changed(sel)" is since sel hasn't been modified by blockcopy as far as I know (especially since the src block in blockcopy is a const, so it's pretty safe). I guess this isn't an issue in Tesseract since they have real time lighting. I haven't tested multiplayer but if it's like undo I think it was recently enabled in multiplayer. The only thing I did so far was adding the autocomplete for prefabs (the same way it works for maps) and a gui /showprefabs which works like /showcustommaps to show the available list of prefabs. This is done entirely in CubeScript so it might have to change if/when we're changing the scripting language. We could also look into binding showprefabs to a key or adding it in the editing menu to make it more usable. Another issue I have noticed is that the /delprefab only deletes the prefab from memory and not in the filesystem (still useful but maybe we could have both: /delprefab to remove from memory and avoid memory leaks and /removeprefab to effectively remove the prefab from the filesystem).

[tdphette]

This looks like the type of feature I would be willing to work on.