#Baker architecture - why isn't this possible?

1 messages · Page 1 of 1 (latest)

dapper girder
# 
        public override void Bake(MyAuthoring authoring)
        {
            //I wish I could do this. :(
            authoring.transform.position = Vector3.zero;

I don't quite understand why this isn't possible. (I mean, it's possible, it just does nothing to the outcome of the bake)

  • either the IComponentDatas are already baked (old system was kind of like this), then I should be able to get them. But they're not yet baked, because if I add my own, a later step will see that it was already added before.
  • or they are not yet baked, will get added after Bake() returns (new system - then I should certainly be able to modify the GameObject and Transforms before?)

I guess Bakers don't have a "PostBake" or "LateBake" thing, and I don't want to write a system for every single authoring component.

So at least I want to understand why this isn't possible. What has the Baking system done already that warrants it both letting my Authoring behaviour make fundamental (!) declaration about the Tansform and its hierarchy (e.g. TransformUsageFlags), yet not interact with the transform itself, and ALSO not interact with the baked LocalTransform etc.?

It would greatly help me plan my asset pipeline structure.

#

To give a real life use example, assuming you want to bake 100 RPG characters.

How do you do it? Do you just mush them all together in a scene at the origin, impossible to spot the leve 38 left corner of the dungeon one that has a broken texture because an artist's finger slipped last week?

small plover
#

baking is just convert authoring data into runtime data
ideally by this point everything should already be authored and setup

#

the question is, why hasn't this already been setup

#

long term i think we really probably want to keep as much logic out of bakers anyway for iteration times

dapper girder
#

So transforms aren't authoring data?

small plover
#

transform is authoring data

#

it is converted into runtime data that matches

dapper girder
#

I think my approach will be: A lineup scene, and a shitload of prefabs, and then a subscene that has nothing but an invisible registry baker object that bakes all the prefabs.

Unfortunately, I think prefabs are a problem when you really want unique entities, instead of going and instantiating each prefab.

dapper girder
small plover
#

Probably because you haven't saved the changes to disk

dapper girder
#

There's a disk operation after Bake() ?

small plover
#

no

dapper girder
#

Ok.

small plover
#

bakers run in a separate process

dapper girder
#

I believed when Bake() runs, this is in its own scene context, much like a EditPrefabContentsScope.

small plover
#

scriptable objects changes aren't reflected in bakers until you save

dapper girder
small plover
#

probably both

#

but i can only confirm standalone assets

dapper girder
#

Wow. I wonder why they did it that way.

#

Nothing in Unity works like that.

small plover
#

because most things in unity use the main process

dapper girder
#

Anway, I should complain less and try to find some solution.

small plover
#

not separate processes, so i'm sure there's a lot of complexities here around it

dapper girder
#

Baking could just be an import worker thing. Prefabs are also processed by multiple input workers.

small plover
#

but import workers don't do things, until the file changes

#

which requires saving it to disk ^^

small plover
dapper girder
#

Ok, I'll call EditorApplication.SaveScene(authoring.gameobject.scene.name) then in my baker. 👿

#

(kidding)

#

My Scenes get rebaked before the Baker code has compiled anyway, so I'm not sure if my Project is beyond saving (pun intended), or if that's really an oversight on Unity's side.

#

It's the most vexing thing, really.

small plover
#

anyway my general opinion is mostly
it may not work how you want it. it might be better if it did, but it'll be a lot less painful experience if you just go with the flow mopK

dapper girder
#

I save a change to baker code, and first it performs a full bake with the old code, in parallel begins compiling, waits until both are done, then reloads the domain, then often (50/50) doesn't pick up on the scene dependency and then I need to manually reimport the subscene.