Blender Raytrace Baker 3.1

[macouno]

Right since I haven't encountered any "reproduceable" bugs, or heard anything that would keep me coding right now...

I decided that today is the day BRayBaker 3 is released.

It is exactly the same as BRayBaker.3.beta.18.py

Except that it's not being developed as such. So for a while at least this is it. And knowing how quick blender is evolving (and the fact that I just did my first source code compilation)... I recon this will have to be it untill something is coded in blender internally.

I happen to know someone is already working on some form of baking using yafray. (won't mention his name cause I dunno if he'd mind).

As before you can get the script here:
http://www.alienhelpdesk.com/index.php?id=22

Also there might be a nr of dead links to older versions in this thread... I removed all but the current one from the server.

And though I repeat myself... if anyone has any images of nice projects they've used the script for I'd love to put one or two up on my site. Or at least to see some results.

Enjoy!
mac

[Gabio]

very cool. This is not only raytrace baker, but total shading baker. Could be used in game also.

Testing right now...

[tedi]

now you only have to add a command that would attach a negative lamp to moving objects to produce fast *soft shadows* :P

btw. bakers and the most vital exporters should be hardcoded into blender ... im. humble op.

[macouno]

Thanks guys.

And yes there is talk of a system that may be coded into blender that may in time be able to do what this script does. But that'll be ages from now if at all... (not me doing it).

Gabio yes... raytrace/texture/shadows/radio/vcollight... anything the renderer can see... but not specularity... cause that depends on the camera angle.

I'll be using it to make textures out of high poly models to stick onto low poly ones... kind of like what they do for unreal 3 or pariah... it'll take some work though

[reD_Fox]

Alright! It's here! Very nice script.
Perhaps you've already seen it, but flippyneck posted an idea similar to what you've implemented. Perhaps when he gets done backpacking (I think that's what I heard he was doing last), you guys could team up.

http://www.elysiun.com/forum/viewtopic.php?t=40051

Anyway, some c & c.
I think you should reassign the mesh's UVs after the render. I switched the section in the code with no problems, so I assume there wasn't a good reason for it happening before the render. The mesh I used the script on was using the UV's to map a texture. Needless to say, it didn't look very good after the script was through with it.

Also, what possibilities are there that would enable a mesh's UV's to remain unmodified? I'm pretty sure it would be a major headache, but it would be extremely useful for baking shadows onto textured game models.

Levi

[macouno]

RedFox: good point about the order in which things happen...

You are right... I can easily make it set the new uv coords after everything is done... that way they won't influense the render at all.

Personally I'd always render a uv textured object to a copy with this script anyway... You know... select the one on layer one, but render layer 2. Especially because in the end product the old uv texture will have become quite meaningless. And this way... you're not lost if you want to change a few things afterwards.

And no... as long as faces can have only one uv layout... there's no way to have it keep it's layout after doing something like this.

I'll do that update later.. probably tomorrow.

[edit] oh yeah and when I started to think about this script I did some searches. naturally I found flippy's and lots more ideas about it... all nice and good but they were all abstract concepts, not people working on making it happen.[/edit]

[Modron]

hey, this looks really cool, man. dangit, i am really going to have to get back to learning how to code. currently, my python shell serves mostly as a calculator. cool script.

[reD_Fox]

Originally Posted by macouno Personally I'd always render a uv textured object to a copy with this script anyway...

Yeah, I know. It didn't do any serious damage.

Originally Posted by macouno And no... as long as faces can have only one uv layout... there's no way to have it keep it's layout after doing something like this.

Well, it would be a different concept, but I'm almost sure it can be done. I'm going to do some poking around with your code to see if I can do something even remotely akin to what I'm thinking. Most of the concepts would be the same, but the final "tiled" render would need to take the form of the mesh's original UV layout, along with some other modifications.
We'll see.

Levi

[macouno]

thanks modron

red_fox...

I understand what you mean now... What you want is to have the meshes that the script now creates to compile the final image to match the original uv coords of the mesh.

So here's what you do.

Create those meshes according to the uv coords of the original mesh (basicly like the tex2uv script does now). It's easy to get those coords out.

This is where you put in the old UV coords for them new meshes.

## Create all the planes with textures.
mez.verts.append( NMesh.Vert( x1, y1, 0) )
mez.verts.append( NMesh.Vert( x2, y2, 0) )
mez.verts.append( NMesh.Vert( x3, y3, 0) )
mez.verts.append( NMesh.Vert( x4, y4, 0) )

For each of those mesh faces set the UV coords as the script gets them... but without the calculation that makes them use a "square tile" grid.

I think (off the top of my head) getting rid of these two lines may do that.
This is where the uv coords are recalculated to match final tile position.

RecUVS[0] = RecUVS[0]/DATAHASH['SQUARE'].val*0.9 + DATAHASH['XFACTOR'].val + (0.05 * (1 / DATAHASH['SQUARE'].val));
RecUVS[1] = RecUVS[1]/DATAHASH['SQUARE'].val*0.9 + DATAHASH['YFACTOR'].val + (0.05 * (1 / DATAHASH['SQUARE'].val));

Then where it now just sets the image texture for those faces... also make it set the texture to use the UV coords.

With some tweaking it should be doable.

Here is the tricky thing though.... UV coords are set with a value from 0 to 1.
So... You would really like to know the aspect ratio of the original uv texture image.
That is... if you want the shape of the texture compilation to match the original uv texture exactly.
It won't be an issue with the uv coords because they stretch as the aspect ratio changes.
If you don't get this right chances are you'll get a lot of stretching.

Also because you get a deformation from the original UV image texture to the model, then to the compile meshes... then from the rendered compilation back to the mesh to the final render.... I dunno how the quality will hold up.

It's really a clever thought though!!! I hadn't come up with that yet
I'll think on it a bit more...

[macouno]

zero found a little error so the script has been updated... same link above will get it.

[reD_Fox]

OK, I've played around a bit, and I think I've found something that will work.

http://members.isp.com/gschooley@isp...ker_test.blend

This is a .blend that describes the process that could be used to modify an original UV texture for a single object. I see it as being most useful for baking shadows and lighting onto objects.
Included in the script is a small piece of python code I ripped off of jms's site and modified (in other words, don't give me credit for it).
The process in the .blend is very manual. I don't have the time to create a script that would automate the process, and I won't until July. If anyone else wants to take this up over the summer, go right ahead.

Anyway, it basically has three steps.
1. Run macouno's script
2. Run my script
3. Render and apply the result

[edit]BTW: This .blend still uses the old version of macouno's script[/edit]

Have fun!

Levi

[Caronte]

This script can be used to generate UV normal maps from a high poly to be mapped on to a lowpoly object?

If so, how?

[macouno]

I have a version here that you can test that retains original UV coords when wanted...

http://www.alienhelpdesk.com/files/BRayBaker.1.2.py

Now I'm still testing it myself... seems to work though you may get some dark edges between "face tiles". Also it's written to work with UV layouts that are set with Square images (for best results).

I have it set to compile using an osa of 16... I can make that another setting, but since it's shadeless anyway it shouldn't be an issue.

redfox: I tried to mail you but get a mail delivery failure message.

Caronte: simple 2 models... one low poly on layer 1 one high poly on layer two... Make sure they're in the exact same position: select the low poly one on layer one, but have the script render layer 2.

[reD_Fox]

Wow! That was fast.
The only complaint I have so far is that some of the UV's are mirrored.
I tested it using the file I posted earlier. The cube on the farthest left had the butterfly mirrored along the UV y-axis, as well as the fox's two ears.
I haven't looked at the code yet, so I don't know how to tell you to fix it.

macouno: About the e-mail issue, I'm not sure what went wrong. I think everything is up and running now.

Levi

[macouno]

Yeah I just found that out... looking into it...

basicly the camera always stays upright now... and so do all uv's... I'm looking into it.

[macouno]

The problem seems to be that my script uses UV's where the 1st vert is always the one in the left bottom corner...

Apparently blender doesn't set up uv's that way by default... actually they're a big hooting mess.

I need a break now so I'll try again tomorrow.

[macouno]

Updated again, same link and filename as before:

http://www.alienhelpdesk.com/files/BRayBaker.1.2.py

I was playing with it, couldn't put my finger on it, so I decided to change some values to reverse engineer the problem.

I reversed the order in which the verts were added to the tile meshes... which I knew was where the problem was and voila... solved!

Don't ask me why though LOL %|

Please test it out extensively.

[lemmy]

Wow, this is great! I had just been waiting for a script like this!

[Rangel]

Macouno, this was one very important tool Blender was missing on its toolset. Thanks a lot for adding it and sharing with the rest of us! Way to go, man!



Any plans of adding YafRay support for the script?

[macouno]

Thanks guys.

I am working on one more improvement: getting rid of "seams" when using your uv coords... it's not too difficult so I should have that online in no time. (perhaps two days)