Page MenuHome

mesh normals in cycles.xml and embedded (texture) files
Closed, InvalidPublicPATCH


this patch adds vertex-normals to the polymesh and an option to embed files. Embedded_files will be hex-decoded and written to disk (if not already there), so they are available as textures. This enables users to create monolithic render files.

Event Timeline

I don't understand why these must be written to disk. Textures are loaded into RAM anyway, are they not?

The process is a bit more complicated. They are loaded into RAM when the scene is constructed. Until then they are just a reference to a file.

There is a mechanism to preload textures as "builtin". But that involves callbacks for parameters and the actual pixels. So it was easier to dump them to disk.

As said above, _the render file is monolithic_. But once loaded into Cycles, it dumps out the texture files into the same directory.
I find this procedure OK, but anyone can object to this.

Adding vertex normals sounds fine, but it still needs some cleanup:

  • Follow the style used all over in Cycles, don't mix your own style in there.
  • Dead code is rather forbidden.

Embedded file support i'm really skeptical about. XML format used by Cycles was never meant to be used as an interchange container. If we want to do it, we need to go away from pure XML and do stuff more like .blend (why not simply to use .blend anyway?).

If others will be fine with such a thing, i'd still really suggest using the same stuff as used for embedded files and movies in blender_session.cpp. Would avoid creating files out of the control actually.

OK, please close this task.

It seems there may be some misunderstanding, will ask about this offline.

I'm trying to team up with @Fábio Santos (fabio) , he's working on the XML exporter that I did not know of before.
I think it makes sense to put everything together - no need for a plethora of separate patches.
Unfortunately there is no way to contact him via blender dev, so I sent him an invite to contact me on BA.
_MAYBE_ you can create that contact.

About using .blend - think of 3rd party programs... There is no .blend-library.
XML is perfect for a quick-hack export (we did that for ZW3D). Contact me at BA and I send you a link of what we've archieved.

Here's the thing. Normals support is almost there, and could go to git real soon IMO. In this respect it kind of makes sense to separate the patches.

As for contacting @Fábio Santos (fabio), why not just start a ML discussion in bf-cycles mailing list to gather all interested people together. Perhaps he's also in that list.

EDIT: Eeh, forgot to mention. .blend was just one of the possible ideas. Just in practice binary formats works MUCH better than ASCII ones. Also, wouldn't mind if someone finally makes .blend file reader library :)

Sure, if I had the time. Unfortunately not the case, but I am willing to help yall.

For completeness sake UV should be added as well but I didnt find any sample code that I could copy/paste (like for normals). That and meshes are somewhat complete. _Anyone_?

And I'd like to see XML export to clipboard instead of that "operator" thingy in the materials editor. That way, people can copy/paste stuff to/from text, and easily share materials. "Groups" (with custom in/output) are missing, but I have an vague idea how to embed that into XML.

I'm right here :) I'm new to the community so I don't know what's the usual method, but a task for this would be nice. I'm working on improving the exporter in github here: . you can post issues there or pull request, and collaborate like that.

As to improving the format itself, I'm not so comfortable with c++ as I am with python but I can do small things like changing the syntax for node links (the current <connect from="nodename socketname" to="nodename socketname"> is pretty suboptimal).

I'm also on the blendercoders irc channel, at times.

I've contacted you on BA, @PRosendalhl, my user there is fabiodan.

Dalai Felinto (dfelinto) claimed this task.

Hi, thanks for your patch.

We are undergoing a Tracker Curfew where we are automatically closing old patches.

If you think the patch is still relevant please update and re-submit it. For new features make sure there is a clear design from the user level perspective.