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.

There is something unstable but I'm not having an easy time reproducing the problem. Yesterday when I started the test scene, I ran it several times and the memory usage often seemed to climb but never return to the original level. Now it's looking more stable, maybe running it over and over was having a cumulative effect. I've tried to reproduce the same conditions but no luck. It seems pretty much the same as master for the 2 setups I tried-> low and medium loads.

I've been setting up some test scenes that have moderate to heavy loads but it's going to take a day or two for the one that has 100 models and 300 textures.

Holding down Alt-Shift when click-selecting should give you a popup menu list of everything that can be selected based on cursor position. Maybe this still works even when other methods fail.