Here's the shader setup I used to create the height map in case anyone working on code wants to bust out custom height-maps for testing purposes. There's a .blend file as well. Any model baked into the height map must simply have the material applied that is named "height" then press f12 for standand camera rendering. There does not seem to be much benefit to rendering more than 8 samples for Emission. That's enough to get perfect anti-aliasing at moderate resolutions. The saved image should be saved as either 16-bit per channel png/tif or some floating point image like exr/hdr.

I should have tested this further before saying anything, the torus just looked so wrong but I think that's because I was using a model that had a depth that was far too dramatic for bump/normals.

@Rainer Trummer (aliasguru)
The dev who started this thread also unassigned and unsubscribed himself from the topic almost 3 years ago.

The is some seam-aware/seam-erasure code that has recently been made available. I'm guessing it's public domain since I can't find any license info.

This is still broken for me but it usually doesn't start right away. When it starts, even my mouse won't work and it also affects texture and curve drawing. If I disable pressure sensitivity then I can make brush strokes again.

@Lukas Stockner (lukasstockner97) What you said sounds good and user-friendly for artists if I understand correctly. Something like the following image is how I'd imagine a nice layout to work, does this match with what you are saying?

@Brecht Van Lommel (brecht) You may be correct in saying that I don't understand UDIM's but I think it's likely a miscommunication. The following is a hand-built UDIM setup that I pieced together just now.

@Lukas Stockner (lukasstockner97) wrote:

When opening an image with 1001 in its name, Blender will not do the usual frame sequence detection.
Instead, it will parse the selected files to check which ones form UDIM textures and assign them to the master tile(s).
Additionally, it will check the folder for other matching tiles, which means that just selecting the 1001 tile is enough.

Auto-detection/loading of the sequence sounds like a nice way to go, however I did not see any mention of how multiple images that have the same UDIM-ID will be treated so I thought I'd bring this up to be sure it's on the table with everything else.

If behind the scenes, Blender were to move the entire scene using the inverse of the camera transform instead of moving the camera itself, then visible close-up models would never be far from the origin. Now round-off/precision errors would likely be mostly eliminated.
It's a huge job that would take an expert in the field (not me of course! :) It would have to appear to the end-user that nothing has changed so far as UI and navigation are concerned.

To add to what Yury included above, if the models use Weight Paint Groups to determine the values for width and segments then multiple objects with different settings can be joined together.

@Dalai Felinto (dfelinto) It looks like I can get away with saying "you're welcome" since no one else is subscribed yet(no one around to annoy with undue email notifications ;). I just wish I had noticed it earlier, I've been too busy to use Blender much since last winter, I just wanted to test the bevel node.

I think what I'd like to see is a threshold that prevents close vertices from overlapping without blocking the movement of vertices that are far from each other. I suppose something like a weighting that diminishes the bevel effect for close vertices.
Something like in the following which shows how Edge-Slide has less impact on close vertices but a large influence on vertices with larger distances. I think this would have to be an option though since it would best suit organic or choppy shapes like rocks. It would likely be inappropriate for machined surfaces.

Howdy Howard :)

To start, I love the new shortcuts added,(p and s)

Using 'Carve' fixes the issue. Head over to the Modifier stack and use the Drop-down menu for the Boolean Modifier to change the solver from BMesh to Carve.

1. I do see the artifacts with GPU rendering(GTX 965m), they are just much more faint.

You fixed it Howard thanks. :) I tried seven models and they all came out fine so far as this bug report goes.

It looks good so far as the results go. The monkey head is coming out error free. The texture is 1024x1024 with 1024 samples.
Both model and sky are white(1.0, 1.0, 1.0)

I finally remembered the keywords to find this document.

It's just the behavior of the UV Image Editor selection tool that makes it seem as if the islands are attached.

I should have also mentioned that you may need to install drivers for your graphics card, sorry, forgot that part. Many people who assemble computers don't bother with this step and it's mandatory in order for the computer to function to its fullest capabilities.

OSX 10.9.5

You should load some screen captures and a .blend file to show what you are seeing.

If you are careful with what you do in Blender, you should be able to get this to work. I'm unsure what you are doing that causes this to fail,

Try installing/reinstalling the Visual Studio Run-time components http://www.microsoft.com/en-us/download/details.aspx?id=40784

It still easy to do. Sculpting on a plane using Inflate brush and Dynatopo from top Ortho view. Blobs appear on the back side of the area that is being worked on.

Might I suggest you try a different idea: Lock down the Projection Matrix and then move its transforms to the next matrix down the chain using the reverse values for each component of position and rotation to give the illusion that the camera is moving.

I tried 'tnear.patch' and it generates a pattern on the model surface that sort of looks like some kind of paper bump texture(the pattern is nice :). The model also becomes very dark when moved far away from the scene origin and away from the axis lines. It looks as if there is a point point nearby and with no scene AO.

I'm not able to reproduce those unsightly error dumps from Blender even when I move the 2.73 config files back into 2.74 which is pretty much what I did a week ago.

Saving defaults is not required to reproduce the OpenGL errors.

./blender --debug-memory --factory-startup was used and I deleted Library->Application Support -> blender -> 2.74 entirely just to be sure.

It's the NSOpenGLPixelFormat GHOST_ContextCGL::initializeDrawingContext() that made me think that there is something going on here with OpenGL. That one keeps coming up randomly.

After thinking about this for a while, I think that using a Segment setting of 1 is the wrong approach for this technique since the tool is forced to make decisions on where the Bevel's virtual faces should end up in UV coordinates.

I wonder if there has been a regression since the following report was resolved. https://developer.blender.org/T38062

https://developer.blender.org/T43339 is almost certainly related.

This should probably be merged with https://developer.blender.org/T43342

Some pattern is showing here. The model is about -2500 units along the y-axis in order to make the error more easily visualized.

Have you been alternating between CPU and GPU rendering? For me, with CPU baking, the error was almost imperceptible and it was only in one small area towards the bottom.

bat3a: in the following diagram we can see that the contrast between the scene size and the facial detail is quite large. The spread between them is approaching 6 decimal places.

For the following .gif, I removed the mirror and moved the model in Object mode then applied the Object's Location using Ctrl+a.

ah.. that's helpful. I guess this is officially archived unless you want to solve the mystery of how Apple Bootcamp driver devs have bungled the US keyboard layout for their dual-boot setup.

Andy makes a good point about baking to Object Space maps first.

From an artists perspective this is easy enough to deal with until a code solution presents itself.

Can you load a screenshot of what you are seeing?

I have two very different results depending on the build I use.

2.73.8 on OSX 10.95, Radeon 6770.

I agree, this should be shelved. Thanks for having a look though. :)

I wonder if this is related to what username:stacker says on the following Blender-SE page about localized keyboards.
http://blender.stackexchange.com/questions/19364/deselect-all-objects-also-on-hidden-layers/19365#19365

one question for you. Did you test this using a WinOS emulation? When you say "attach it" are you expecting a file to be printed somewhere. I've looked and don't see anything obvious laying around and WinOS consoles don't seem to allow copy/paste operations. Here's a screen-capture instead.

At 4096x4096, the artifacts are very difficult to spot compared to the 1024x1024 version.

The artifacts are still showing up, the first image shows the results without rB7b16fda/rB1b92dfa96160

I've added another bug report with a different node which may have a similar solution to the one found here. https://developer.blender.org/T43755

Here's a flow chart that should work (for me at least :)

I left out the texture since it's 2048x.

Here's another test. The first render is done with 2.73 official. The second is done using a build that has this new change(commit rB7b16fda3799d). Both use identical settings. The usual monkey head, Smart UV Project(default Settings). Direct Lighting, Branched path tracer 256 AA samples, the other samples are all set to default '1'. The material is Diffuse white(1,0, 1,0, 1,0) and the sky is also white(1,0, 1,0, 1,0).

user:karja has me convinced this is a really good idea. Normally for some of the things shown in his(her) posts, people tend to use a stand-in object that is complete and seamless while the breakable object is invisible. Then the object is made to "brake" by reversing the visibility of everything at a certain keyframe, it works but this idea for a Remove Doubles modifier seems neater and would be very easy to setup and maintain.

It seems that the reason this was removed is because it ruins the baked result for the Combined pass. I've posted a test result at https://developer.blender.org/T43388

Some bad news to go with the good news. It seems that this change is only useful for situations that do not involve lighting. For the Emit pass, it appears to offer and improvement of the standard method, when using GI, the resulting bake has very distinct black artifacts across the entire image.

Maybe people can offer suggestions on the actual tips, that would be very useful to others and saves the devs a whole lot of time trying to guess what is common knowledge or not.

Textfield hover copy and Paste is one of those things that's super useful but not so easy to stumble upon.

@Dalai Felinto (dfelinto), it does more than just fix the problem, it improves the quality substantially over normal rendering for the same amount of samples.

Resetting to factory defaults doesn't fix the problem. I did boot into OS X and I was mistaken about the problem also showing up there, it's fine. So it's only under Windows that this is happening(or not happening :)

One or two check-box's for 40 other small different features that people want would cause bloat, the UI already has problems with this. That's what tabs were meant to address.

I think part of the issue is feature bloat and the UI clutter that comes with this. Maybe this could be solved by not exposing this in the UI.

Also, the problem started sometime after Hash: 0034be9 (Oct 06)

The offset seems to be influenced by the object dimensions. I've applied Scale after re-sizing but the results seem the same either way.

liquidApe: "I tap "Tab" for instance and it quickly flashes into edit mode, and then flashes back to object mode."

Maybe you could do what Campbell said needs to be done. You could start laying the groundwork for changes to Blenders underpinnings instead of working around them and cloning code.

Maybe you could leave the physics simulation out for now and leave it up to the user to add this if necessary. There is actually a pretty good use for this modifier without any simulation as in the case of jade-like stone that is translucent and has fissures.

I have just found a situation that reproduces this.

I've seen this many times. I've tried baking models when this is happening and didn't notice it right away. It shows up in the baked texture as torn triangles.

Reporting Bugs in Blender from Sebastian König http://vimeo.com/75649649

Personally, I would very much like to see Select Inner on by default. This is one of the tools I use the most and I almost always have to toggle this option since the Inner faces tend to be the ones I plan on working with next.

Here's an image that shows the basic setup for a benchmark test I've setup. The image only shows 4 monkeys but the benchmark has 100 of them. Each monkey head has a Sub-D modifier at 2 iterations. There are 300 textures and 200 of them are 2048x2048 input textures. The other 100 are 1024x1024 and these are the textures being baked to. All of the bake-to textures should already be selected for every material.

that was CPU rendering. I built 2 versions. First I updated from GIT, then I built 1 from master and then I applied the patch and built again and named it D722. As I said, it may not even be the patch that's the problem. Whatever was happening yesterday did not happen today when I actually had a screen recording going so I could log the very noticeable RAM climbing.