Standardize TypedWritable about panda3d HOT 2 OPEN

Thank you for sharing your frustrations.

We can't use a vtable call for register_with_read_factory since those can only be done on an already-constructed object. I'm not sure what the Panda designers' reason was to create a separate method for this, it does seem slightly unnecessary. I'd be happy to consider a change to directly call register_factory in the config files.

The reason why we do need a separate virtual fillin method is that further updates to a particular object will end up needing to call fillin again in order to adopt the changed fields. This is useful when synchronizing Panda scenes over a socket connection.

For the default TextureStage, it is important that it is always resolved to the singleton default TextureStage, so checking the field and returning this pointer in make_from_bam was the easiest way to implement this. This isn't actually the best way to implement this, since it breaks when streaming changes to this object. It should instead just "peek" at the first value in the datagram, or it should implement change_this like RenderState does.

I wasn't aware of the existence of those templates or documentation files. I agree we need to update or remove them, and also update the remaining cases of factory functions that are not called make_from_bam.

Please note the existence of this document, which contains my own notes as I wrote my own bam writer library, though it looks like you might already be largely past the point where this might be useful.

from panda3d.

We can't use a vtable call for register_with_read_factory since those can only be done on an already-constructed object. I'm not sure what the Panda designers' reason was to create a separate method for this, it does seem slightly unnecessary. I'd be happy to consider a change to directly call register_factory in the config files.

Ah, right. The only reason I could see keeping registration in each cxx is to keep all class-specific behavior there, but now that every registered function is called make_from_bam and is easy enough to find, it'd be better to centralize it in the config files.

The reason why we do need a separate virtual fillin method is that further updates to a particular object will end up needing to call fillin again in order to adopt the changed fields. This is useful when synchronizing Panda scenes over a socket connection.

Makes sense, I haven't looked into runtime behavior much yet.

Please note the existence of this document, which contains my own notes as I wrote my own bam writer library, though it looks like you might already be largely past the point where this might be useful.

Saves me the work of having to go through each bam revision when adding crate documentation, thanks!

from panda3d.