[Bf-gamedev] Cycles baking workflow

Sun May 11 12:26:41 CEST 2014

Hello Dalai!
Thanks for your video on how to use the baking functionality.
https://www.youtube.com/watch?v=jC1hrN3z_7M&feature=youtu.be&a

So now I must admit that the current workflow really makes sense, in that it’s consistent and fits with other blender’s rendering and image manipulation workflows, and it gets the job done, somehow.

The problem is that those workflows are very bad.

What got me troubles to make baking works properly was the fact that you need to use an input node as an output node. As a long time Shake user I would have never been able to figure by myself that an image texture node (that I use to IMPORT image files), connected to nothing, would serve to OUTPUT an image!?

Compared to Shake (which is my favorite software of all times), the blender’s node editor is extremely confusing and makes simple things very complicated.

In your videos, we can see you being confused a few times as you don’t get what you expect, and you are the developer of the features. Now imagine a user new to blender trying to get his way into this!

So now I understand the choices that were made just before merging the bake features into master. It totally makes sense to keep a coherent workflow but the underlying problem is that the workflow itself is incoherent.
I think that the blender usability issues raised by Andrew Price needs to be taken care of. But this is going off this topic.

What to choose next? :
- The bake functionality stays in the current workflow, and no one will understand it.
- The bake functionality does the rebel and stays out of this mess with it’s own workflow.
- Rebuild the node editing features so it can unleash it’s huge potential. If the node editor was working properly, and used in other areas of the software, Blender could be king of the world.

Thanks.
Best regards,
François Roussel

Le 9 mai 2014 à 16:14, François Roussel <F-R at F-R.tel> a écrit :

> Hello Dalai and thanks for your answer!
> 
> So I have to admit that it seems that I don’t currently understand the actual workflow and the blender doc is not helping me.
> So could you expose here what is the proper workflow when working with cycles and how are we supposed to use the baking feature the way it is in the master? What is the active texture workflow?
> You said that it is possible to to specify an image size indirectly, how?
> 
> The actual workflow for my game project is based on VRray which has a very simple and efficient baking functionality.
> 1 - Specify the object you want to bake.
> 2 - Specify which UV channel to bake (extremely useful if you have a uv map for classical texture assignment and another one for the lightmap).
> 3 - Eventually set two settings : dilatation, for extra pixels around geometry and a flip derivative bool to reverse bump mapping.
> 4 - HIT RENDER it renders at the specified resolution and saves at the specified output destination.
> (Screen grab of the vray bake section).
> <VRayBake.png>
> 
> What is great with that simple setting is that it can be very easily automated. I made a very small python script that changed automatically the object to bake and the name and location of the output file. I could also quickly switch a variable to produce preview renders or final renders by changing automatically the rendering resolution.
> 
> You can download the patched blender for vray here :
> https://github.com/bdancer/vb25-patch
> You can also install vray demo to give it a try  from here :
> http://www.chaosgroup.com/
> 
> So for me the VRay workflow is totally finel. Just as your first proposal before it was merged to master and changed to what it is now.
> 
> I also went through the pages of the Blenderartists forum and found very valuable informations.
> http://blenderartists.org/forum/showthread.php?326534-Cycles-baking-is-here
> 
> Your interface proposal you made late march (see included file) was absolutely amazing, not to say that it’s the baking dream tool. Just make it possible to monitor the rendering progress, and blender will have the best baking tool out there!
> <bake-maps.png>
> 
> Now, I would really love to try your new branch but for some reason I can’t compile the current version of blender. Everything was fine until the switch to 2.71, now I’m completely lost, my modest developer skills are not up to the task. Once again, the docs and various bits here and there of more or less dated informations are of no help… That’s also one thing that I think blender is missing : a decent up to date and centralized documentation.
> So if you can help me on the compilation side that would be really nice!
> 
> So, to sort things out :
> 1 - The current workflow seems completely inappropriate - unless I completely misunderstood it.
> 2 - Your first builds were totally decent, and able to compete against solutions like Vray. it was simple, everything seemed to be in place and working.
> 3 - By judging your screen shot on blenderartists forums, you were just about to release a baking war machine ready to kick every competitors out of the game. That’s too bad that at the last minute it didn’t happen…
> 
> I don’t see the need to make workflow proposals as you already had what looks like the best solution.
> We can eventually think of a dedicated baking editor with a table containing baking properties for each concerned objects. But this is maybe too ambitious and could lead to something overly complicated.
> 
> I also speak here only about my needs for a game that is technically quite simple and won’t require techniques like normal baking with cages and stuffs. So I’m far from being representative of the game devs that will need these tools.
> 
> I hope it helped moving forward!
> 
> Best regards,
> François Roussel
> 
> 
> Le 7 mai 2014 à 18:35, Dalai Felinto <dfelinto at gmail.com> a écrit :
> 
>> First for those not following the latest Cycles development here is
>> what is going on:
>> 
>> During the development we had an option to simply dump the baked map
>> in an external file, defined by a filepath. Prior to the merge in
>> master, we decided to hold on this workflow in favour of something
>> more aligned with Blender current design. I'll call it the "Active
>> Texture" workflow.
>> 
>> We are basically using the same criteria that is used in the Viewport
>> and for Projection Painting as to determine which texture each
>> material should bake. Some of the downsides mentioned in the
>> BlenderArtists thread are:
>> 
>> * You can't specify the final size directly (it depends on the images
>> you are using)
>> * Blender doesn't automatically save the images
>> * It requires adding new materials and Image Texture nodes for the
>> 
>> Note that, apart from the requirement of adding new materials, this is
>> the same issue one would face with the Blender Internal baking.
>> 
>> There are different ways of solving the "this workflow is bad" issue.
>> We can improve this workflow (e.g., we could have an option to
>> autosave the images after the bake). We can ditch it entirely (proven
>> that a new workflow is superior to this in all its aspects). We can
>> propose something that can live in parallel. Initially I was
>> personally in favour of ditching the internal saving :) but Campbell
>> helped me to see that it has some advantages that "external saving"
>> didn't have.
>> 
>> Either way, we need a solid proposal here. The rest of the email is
>> addressing your request for external saving:
>> 
>> Hi François,
>> 
>> You are not the first one to suggest having external saving back. In
>> fact due to popular request I'm keeping a branch in github with the
>> original external saving, to help those already requiring cycles
>> baking into production.
>> 
>> https://github.com/dfelinto/blender-git/tree/bake-cycles-external
>> 
>> That said, we should take the time to design a proposal on how to
>> tackle this eventual need. But I haven't heard a proper proposal other
>> than "please let's have external saving back" ;). Some things to
>> consider:
>> 
>> * How to handle multiple materials using different images (think of a
>> car where the wheel and the trunk are to be mapped to different
>> images, each of them taking the entire image area).
>> 
>> [in the branch this is what I called the "Split Materials" option]
>> 
>> * How to preview the result? I can see that the maps are a final
>> result, like a render, thus you often need them elsewhere. However to
>> have to open the image internally, and apply it to the active object
>> is not very practical either. Building a solution on top of the
>> "active texture" workflow gives you "for free" the viewport preview of
>> the baked map.
>> 
>> * How to re-bake separate objects without having to re-set the filepaths, ...
>> 
>> [part of this is handled by the "Automatic Naming" option in the branch]
>> 
>> As you can see some of those are better solved by using the active
>> texture workflow (for those not aquictanced with that, we are using
>> the same criteria that is used in the Viewport and for Projection
>> Painting as to determine which texture each material should bake).
>> 
>> 
>> Best regards,
>> Dalai
>> --
>> blendernetwork.org/dalai-felinto
>> www.dalaifelinto.com
>> _______________________________________________
>> Bf-gamedev mailing list
>> Bf-gamedev at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-gamedev
> 
> _______________________________________________
> Bf-gamedev mailing list
> Bf-gamedev at blender.org
> http://lists.blender.org/mailman/listinfo/bf-gamedev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-gamedev/attachments/20140511/5aadda71/attachment.htm 