- User Since
- Feb 11 2007, 4:11 PM (699 w, 5 h)
May 15 2020
It depends on the context, but generally "distance" is the correct terminology for baking when using a uniform ray distance, as you are setting the distance the rays will travel before being cast back inward. Renaming it Max/Maximum Ray Distance is fine ofc., but I would say that "Extrusion" is correct when referring specifically to a cage, as you are inflating or extruding the mesh (either visible or in the BG) used for projection beyond its initial size. Distance has somewhat of a different meaning in cage baking as you are setting the cage size in order to control the ray distance (and sometimes direction), rather than setting the ray distance explicitly.
Sep 27 2019
Sep 25 2019
May 12 2019
Thanks for the reply!
Apr 17 2019
Mar 29 2019
Feb 7 2019
Thanks for the thought you are putting into this @William Reynish (billreynish)
Feb 6 2019
@William Reynish (billreynish) Thanks for the reply.
Yes, it was an intended change, but it was still a change based on false information. A user shouldn't be able to simply report anything as a bug because they don't understand how a tool works and because someone already changed the code force everyone else to live with the error.
@Sebastian Parborg (zeddb) with respect, this is absolutely not a feature request. My initial report was due to a regression in functionality due to other users erroneous bug reporting.
Jan 26 2019
Any more thoughts on this @William Reynish (billreynish)
It would be great to get a solution ready for 2.8 :)
Dec 30 2018
Sorry for the late reply. I've only just noticed that this thread had replies.
May 2 2018
Generally I think it is desirable to recall any values that have to be entered manually into a tool from the last use (including bevel), as consistency in such things is essential to solid modelling. Hopefully we can get this sorted out to mutual benefit for all users.
Thanks for the reply @Philipp Oeser (lichtwerk)
May 1 2018
Jun 27 2017
Thanks for the reply @Brecht Van Lommel (brecht)
Jun 26 2017
Is it possible to at least get a checkbox to use Rdq so users can pick their choice of roughness standard? I use Rdq on a regular basis in situations where roughness squared is not usable without conversion.
Thanks for the reply, Brecht.
Jun 25 2017
Aug 19 2016
Jul 22 2016
Jul 15 2016
Jan 4 2016
Yup, sure thing. It seems the cage wasn't expanded enough (though it looks ok at first glance). Alt+S>Apply scale on the cage fixed the issue.
Aug 28 2015
I just wanted to chime in and say that while 32bit float does fix this problem, unfortunately it isn't really a workable solution for the purposes of most production (realtime at least) as 32bit float textures are a massive overkill for normal maps in terms of wasted memory and other resources. This is especially true for things such as games as the texture is going to be compressed down to DXT1/5 or at best BC5 anyway.
May 1 2015
I think this sounds like it could be a very useful tool indeed.
Mar 12 2015
Forgot to check this. Sorry!
Feb 22 2015
Interesting. I will take a look tomorrow
Feb 11 2015
That was fixed fast :)
Dec 30 2014
Dec 29 2014
I have no idea how the new hash system from Github works but I just tested with r5ea243b and the issue is still there.
Dec 26 2014
Sorry for the late reply! I have been checking this periodicity and havent had time to post.
Dec 15 2014
I updated the Wiki page with a new link for the download because the old link redirected to https://developer.blender.org/maniphest/
Nov 12 2014
Oct 11 2014
+1 I think is a modifier that would be worth adding even if it were only for pure modeling purposes.
There are many occasions where I would rather work procedurally (via a curve) but then have to turn it into a mesh because there is a seam.
Aug 28 2014
Aug 27 2014
Crosspost from the mailing list as I didn't get a reply there.
May 6 2014
Yes, it would be nice if both BI and Cycles had the ability to use cages as they are a superior way to bake.
Uniform ray distance has so many issues when it comes to baking with hard/sharp edges. :)
May 5 2014
Feb 20 2014
Sounds fair to me. Would be useful indeed :) +1
Feb 17 2014
I would still say your request is valid. I'm an env artist and all the concepts/blueprints I use need to be centred in Blender before using them. :)
It really depends on if people are using concept art/reference or as you say a blueprint. I would assume that we have more regular artists vs arch viz peeps so I would still think the change would be a good one.
+1 to the changing of the Image type Empty defaults to @Mikhail Rachinskiy (alm)'s suggestions above. :)
Feb 13 2014
VBO's On IMHO. There doesnt seems to be any downsides to this really.
@xrg (xrg), Yes, I understand what the UV sculpt is for :) My point is that it is UV tool and people will want to keep all UV tools together for consistency. At least I do. :P
Feb 11 2014
Just want to chime in real quick and give my support for not splitting UV and UV sculpt tools up.
It's bad enough that we cant work in full screen when doing UVs currently without adding multiple tabs for one job into the mix too. :)
Thanks for the reply @Andrew Buttery (axb)
It's just super frustrating to work one way for years and then have it changed all of a sudden. This wasn't a minor change and like I said before I can understand that people would want to switch the hotkeys...I just don't feel that it was needed to change the position or the pop outs, especially since there wasn't any massive outcry or anything. Currently this is just causing me headaches. :P
Feb 10 2014
@Andrew Price (andrewprice), Fair enough but I still have to disagree with you there, mate. :P
Feb 9 2014
I really don't know why everyone loves such light wireframes so much :P
Feb 4 2014
@Jonathan Williamson (carter2422), I just increased the gap between the tabs and the end of the interface on the left hand side by a couple of pixels.
@Jonathan Williamson (carter2422), After using the new tabs for a while I feel that they are perhaps a little cramped horizontally. I did a mockup with an increased gap on the left hand side of the tabs and think that it allows the design to breathe a little more.
Jan 29 2014
I really don't understand the problem with turning off double sided to be honest. It's super obvious when a normal is pointed inward as the face already renders black and people should always be modelling with normals outwards anyway as a matter of course, unless they have specifically chosen to do otherwise on purpose.
Jan 28 2014
@Jonathan Williamson (carter2422) No real crits, atm, other that what I have already spoken to you about. Looking good, mate.
@Matjaž Lamut (lamoot) I don't think that backface culling should be changed tbh. It's often very useful to see geometry that is only lit from one side just so you can see that there is geometry there an that would be removed if culling was enabled. It's better to see a black face than no face at all and it is easy enough to flip/recalc normals, which is something all artists should be aware of anyway.
Double sided off should be enough I think. :)
Regarding double sided I think as there is no performance gain to having it on but a vast performance gain to having it off by default we should do just that. Perhaps it will make little difference to AMD/ATI uses (from what I hear) but for Nvidia GPUs it makes a huge difference in performance. Perhaps we could have an option in the prefs to allow people to choose?
Jan 23 2014
How it worked in 2.68 is fine tbh, mate. It's really pretty important to see how geometry is triangulating so you can fix errors by modifying vertex positions or by changing edge flow etc. without having to apply the modifier.
In an ideal world people could rotate edges and store their positions actually within the Triangulate modifier but I think that is quite a bit of work to do.
Jan 9 2014
@Brecht Van Lommel (brecht), Awesome, thanks! I will give it a test over the next few days with a build from buildbot. Cheers :)
Jan 6 2014
@DataDay (DataDay), Glad to be here, mate! :)
Jan 5 2014
@Mikhail Rachinskiy (alm), mmhm, try loading a scene with 40 million tris of raw geo and see what happens :)
I'm not super keen on light wireframe colours tbh. I find it much easier for to read black wireframes on a grey object than light wireframes on a grey object.
I would be up for a darker theme by default though.
It would be nice if we could we add something like FXAA as an option in addition to MSAA. Its way cheaper to run and similar in the look of MSAA with some minor differences, but obviously the user would have to be in GLSL mode to use it.
Jan 4 2014
Brecht, of course you are correct that 127.5 is the ideal value but 128 is expected as the flat colour in UDK and other engines and can actually cause errors in 8bit within those engines when mirroring. Most artists expect 128 as the flat colour too. If you could round it up to 128 that would be great as it might stop some headaches down the line.
I can confirm that the values are indeed off by a little, though I get different values for different areas.
If you split the areas in the bake into quadrants the top and bottom give a value of 128, 128, 255/#8080ff where as the sides give a value of 128, 127, 255/#807fff. The centre of the bake gives a value of 127, 127, 255/#7f7fff.
Nov 25 2013
Ahh no, you were perfectly clear. I just wanted to make sure that I was too. :)
I don't have a problem with this change really.
As long as I don't actually have to go into face mode to use the tool and will still be able to select a face via vert. selection that I'm happy. Maybe adding a error message saying that a face needs to be selected would help too?