Re: [Bf-committers] Inverse Shrinkwrap? (only keep above surface)
Found this can be done already (sort of), Project negative then cull front or back. There was a bug where rotating the object made culling fail, fixed r34986. This works ok with a sphere/cube and sphere/plane so in real usage there may be some other options needed. If this isn't working well I'd be interested to see an example blend file. On Fri, Feb 18, 2011 at 8:02 PM, Daniel Salazar - 3Developer.com zan...@gmail.com wrote: Thumbs up for suggestion. For group behavior lets just wait for nodal modifiers, this will be a no brainer with a forgroup loop node cheers Daniel Salazar 2011/2/18 ra...@info.upr.edu.cu: Hi May be my recent released relaxation patch can help http://www.box.net/shared/ddhtfnsq75 HI guys! As I see it, shrinkwrap is lacking of two things that would make it even better. 1_ A Neighboring vertexes smoothing factor. This would be done by applying a kind of falloff to the affected surface like in these examples: http://chrisevans3d.com/tutorials/maya_muscle.htm 2_ An algorithm that determines that if a vertex movement goes out of a certain distance range, those vertexes should be smooth out or its movement averaged with the movement of the neighboring vertexes. This feature could avoid vertex artifacts with an articulated object, specially in projection mode. Maybe this is too much to ask from Campbell's weekend quick fix, but you never know when Jaguarandi is reading :p Date: Fri, 18 Feb 2011 14:26:55 +0100 From: tobias.oelga...@googlemail.com To: bf-committers@blender.org Subject: Re: [Bf-committers] Inverse Shrinkwrap? (only keep above surface) Using a group of objects could be useful, but if it's not done for multiple objects, you still can just apply multiple shrinkwraps in keep above only mode to achieve more or less the same result. In many cases it would be just one collision object and fine. Of course groups of objects would move the vertices more correctly. But as you said: One step at a time. The first one alone would already be great. Am 18.02.2011 14:14, schrieb Campbell Barton: You're right that this is simple to add and agree it seems very useful, quick way to reducing intersections without physics errors. The main downside I can see, as the verts slide over large variance it could give visible popping in some cases, though this is no difference then shrink-wrap for other uses. Though it makes me think for this feature it would be even more useful in production is if the modifier could select a group of objects to 'not pass through', rather then a single one. But one thing at a time, this seems reasonable and if theres no objections I can add this over the weekend since I made some changes to this area recently. On Fri, Feb 18, 2011 at 12:43 PM, Tobias Oelgarte tobias.oelga...@googlemail.com wrote: Shrinkwrap is designed to force vertices onto the surface of another object. In Nearest Surfacepoint mode it moves vertices either to the surface or optionally let it also move outward until they are on the surface. So you can work with essential two options. But wouldn't it make more sense to include also the possibility that vertices can also only be moved up onto the surface and and not moved toward it? It would allow you to throw a ball against a window, making the vertices stop that would pass trough it. There are many possible usages i could think of: Bubbles in a glass. Shoes that not sink slightly into the ground. Body parts that collide with each other, and many more. Since the algorithm seams to handle this case already -- knowing if a vertex is inside or outside the target, for Keep above surface -- it should be just an additional option. Am i right? Cases (now): * Shrink to Surface * Shrink to Surface and move outward for keep above Cases (desired): * Shrink to Surface * Only keep above * Shrink to Surface and move outward for keep above Hope this is a little inspiration. It would make shrinkwrap much more awesome. Greetings from Tobias Oelgarte ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell ___
Re: [Bf-committers] Inverse Shrinkwrap? (only keep above surface)
Currently i did some tests and it shows that the behavior of projection and and nearest surface point is way different. Projection also makes the vertices jumping. I tested it with svn rev34989 and appended an very simple example. Just use the shapekey-slider (Key 1) of the red inner object (something like a muscle) and you will see that the skin is snapping. First nothing, then a jump, followed by a smooth further transition. That is unacceptable for muscles and in many complex cases even worse. Example file: http://www.pasteall.org/blend/5290 Am 19.02.2011 10:16, schrieb Campbell Barton: Found this can be done already (sort of), Project negative then cull front or back. There was a bug where rotating the object made culling fail, fixed r34986. This works ok with a sphere/cube and sphere/plane so in real usage there may be some other options needed. If this isn't working well I'd be interested to see an example blend file. On Fri, Feb 18, 2011 at 8:02 PM, Daniel Salazar - 3Developer.com zan...@gmail.com wrote: Thumbs up for suggestion. For group behavior lets just wait for nodal modifiers, this will be a no brainer with a forgroup loop node cheers Daniel Salazar 2011/2/18ra...@info.upr.edu.cu: Hi May be my recent released relaxation patch can help http://www.box.net/shared/ddhtfnsq75 HI guys! As I see it, shrinkwrap is lacking of two things that would make it even better. 1_ A Neighboring vertexes smoothing factor. This would be done by applying a kind of falloff to the affected surface like in these examples: http://chrisevans3d.com/tutorials/maya_muscle.htm 2_ An algorithm that determines that if a vertex movement goes out of a certain distance range, those vertexes should be smooth out or its movement averaged with the movement of the neighboring vertexes. This feature could avoid vertex artifacts with an articulated object, specially in projection mode. Maybe this is too much to ask from Campbell's weekend quick fix, but you never know when Jaguarandi is reading :p Date: Fri, 18 Feb 2011 14:26:55 +0100 From: tobias.oelga...@googlemail.com To: bf-committers@blender.org Subject: Re: [Bf-committers] Inverse Shrinkwrap? (only keep above surface) Using a group of objects could be useful, but if it's not done for multiple objects, you still can just apply multiple shrinkwraps in keep above only mode to achieve more or less the same result. In many cases it would be just one collision object and fine. Of course groups of objects would move the vertices more correctly. But as you said: One step at a time. The first one alone would already be great. Am 18.02.2011 14:14, schrieb Campbell Barton: You're right that this is simple to add and agree it seems very useful, quick way to reducing intersections without physics errors. The main downside I can see, as the verts slide over large variance it could give visible popping in some cases, though this is no difference then shrink-wrap for other uses. Though it makes me think for this feature it would be even more useful in production is if the modifier could select a group of objects to 'not pass through', rather then a single one. But one thing at a time, this seems reasonable and if theres no objections I can add this over the weekend since I made some changes to this area recently. On Fri, Feb 18, 2011 at 12:43 PM, Tobias Oelgarte tobias.oelga...@googlemail.comwrote: Shrinkwrap is designed to force vertices onto the surface of another object. In Nearest Surfacepoint mode it moves vertices either to the surface or optionally let it also move outward until they are on the surface. So you can work with essential two options. But wouldn't it make more sense to include also the possibility that vertices can also only be moved up onto the surface and and not moved toward it? It would allow you to throw a ball against a window, making the vertices stop that would pass trough it. There are many possible usages i could think of: Bubbles in a glass. Shoes that not sink slightly into the ground. Body parts that collide with each other, and many more. Since the algorithm seams to handle this case already -- knowing if a vertex is inside or outside the target, for Keep above surface -- it should be just an additional option. Am i right? Cases (now): * Shrink to Surface * Shrink to Surface and move outward for keep above Cases (desired): * Shrink to Surface * Only keep above * Shrink to Surface and move outward for keep above Hope this is a little inspiration. It would make shrinkwrap much more awesome. Greetings from Tobias Oelgarte ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org
Re: [Bf-committers] Inverse Shrinkwrap? (only keep above surface)
If you reduce the offset to 0.0 then the problem is not visible. It only happens with offset different from 0. Offset is ignored, until original mesh, without offset, is reached. Am 19.02.2011 14:24, schrieb Tobias Oelgarte: Currently i did some tests and it shows that the behavior of projection and and nearest surface point is way different. Projection also makes the vertices jumping. I tested it with svn rev34989 and appended an very simple example. Just use the shapekey-slider (Key 1) of the red inner object (something like a muscle) and you will see that the skin is snapping. First nothing, then a jump, followed by a smooth further transition. That is unacceptable for muscles and in many complex cases even worse. Example file: http://www.pasteall.org/blend/5290 Am 19.02.2011 10:16, schrieb Campbell Barton: Found this can be done already (sort of), Project negative then cull front or back. There was a bug where rotating the object made culling fail, fixed r34986. This works ok with a sphere/cube and sphere/plane so in real usage there may be some other options needed. If this isn't working well I'd be interested to see an example blend file. On Fri, Feb 18, 2011 at 8:02 PM, Daniel Salazar - 3Developer.com zan...@gmail.com wrote: Thumbs up for suggestion. For group behavior lets just wait for nodal modifiers, this will be a no brainer with a forgroup loop node cheers Daniel Salazar 2011/2/18ra...@info.upr.edu.cu: Hi May be my recent released relaxation patch can help http://www.box.net/shared/ddhtfnsq75 HI guys! As I see it, shrinkwrap is lacking of two things that would make it even better. 1_ A Neighboring vertexes smoothing factor. This would be done by applying a kind of falloff to the affected surface like in these examples: http://chrisevans3d.com/tutorials/maya_muscle.htm 2_ An algorithm that determines that if a vertex movement goes out of a certain distance range, those vertexes should be smooth out or its movement averaged with the movement of the neighboring vertexes. This feature could avoid vertex artifacts with an articulated object, specially in projection mode. Maybe this is too much to ask from Campbell's weekend quick fix, but you never know when Jaguarandi is reading :p Date: Fri, 18 Feb 2011 14:26:55 +0100 From: tobias.oelga...@googlemail.com To: bf-committers@blender.org Subject: Re: [Bf-committers] Inverse Shrinkwrap? (only keep above surface) Using a group of objects could be useful, but if it's not done for multiple objects, you still can just apply multiple shrinkwraps in keep above only mode to achieve more or less the same result. In many cases it would be just one collision object and fine. Of course groups of objects would move the vertices more correctly. But as you said: One step at a time. The first one alone would already be great. Am 18.02.2011 14:14, schrieb Campbell Barton: You're right that this is simple to add and agree it seems very useful, quick way to reducing intersections without physics errors. The main downside I can see, as the verts slide over large variance it could give visible popping in some cases, though this is no difference then shrink-wrap for other uses. Though it makes me think for this feature it would be even more useful in production is if the modifier could select a group of objects to 'not pass through', rather then a single one. But one thing at a time, this seems reasonable and if theres no objections I can add this over the weekend since I made some changes to this area recently. On Fri, Feb 18, 2011 at 12:43 PM, Tobias Oelgarte tobias.oelga...@googlemail.comwrote: Shrinkwrap is designed to force vertices onto the surface of another object. In Nearest Surfacepoint mode it moves vertices either to the surface or optionally let it also move outward until they are on the surface. So you can work with essential two options. But wouldn't it make more sense to include also the possibility that vertices can also only be moved up onto the surface and and not moved toward it? It would allow you to throw a ball against a window, making the vertices stop that would pass trough it. There are many possible usages i could think of: Bubbles in a glass. Shoes that not sink slightly into the ground. Body parts that collide with each other, and many more. Since the algorithm seams to handle this case already -- knowing if a vertex is inside or outside the target, for Keep above surface -- it should be just an additional option. Am i right? Cases (now): * Shrink to Surface * Shrink to Surface and move outward for keep above Cases (desired): * Shrink to Surface * Only keep above * Shrink to Surface and move outward for keep above Hope this is a little inspiration. It would make shrinkwrap much more awesome. Greetings from Tobias Oelgarte
[Bf-committers] normal maps, red/green channel inverted
Hi all, Blender is exporting normal maps with red and green channel inverted relative to the geometry we actually export with our exporters and I would very much like to fix this. This would make blender export normal maps which are very similar to most tools out there and it would make sense to people trying to use them in their own engines. What we are talking about is a very minor tweak. There's one place that writes them and two places that read them. I would only have to do a minor adjustment there. It will be different from maps baked with blender previously but then that ship has already sailed when we gave normal maps the overhaul that we did to support mirroring, order-independence of faces, vertices on faces, welding etc. So when you think about it this is a relatively minor tweak in comparison. So I am thinking might as well do it proper. Kaito has asked me to ask you guys if you are ok with it? Here's hoping for the best :) Thanks, Morten, ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] MinGW debug builds do not run
Tested it with cmake too. It links after a small fix, but crashes immediately after starting. Seems mingw isn't supported. Peter ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] normal maps, red/green channel inverted
Am 19.02.2011 16:22, schrieb Morten Mikkelsen: Hi all, Blender is exporting normal maps with red and green channel inverted relative to the geometry we actually export with our exporters and I would very much like to fix this. This would make blender export normal maps which are very similar to most tools out there and it would make sense to people trying to use them in their own engines. Good! It will be different from maps baked with blender previously but then that This does mean that old scenes render incorrect? Just to clarify. Or will there be some compatibility switch? Carsten Kaito has asked me to ask you guys if you are ok with it? Who's that guy hanging around there all the time? ;-) -- Carsten Wartmann: Autor - Dozent - 3D - Grafik Homepage: http://blenderbuch.de/ Das Blender-Buch: http://blenderbuch.de/redirect.html ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] normal maps, red/green channel inverted
This does mean that old scenes render incorrect? Just to clarify. Or will there be some compatibility switch? Mario (lmg) suggests we'll throw in a commandline for how to do batch convert in image magic. The inversion we're talking about corresponds to ctrl+i in photoshop btw. It's essentially (in 8 bit): val_new = 255 - val_cur; applied to red and green. This will make the normals stored in the map correspond to tangent space generated from the geometry we actually export in all of our exporters. Like I said since we have already done an overhaul on how normal maps work to get them to work properly and support mirroring, face/face verts order-independence, welding independence etc. We might as well be sure to get it right now. Seems like now or never, And this is a small adjustment on the change that is already in anyway. Cheers, Morten. On Sat, Feb 19, 2011 at 7:51 AM, Carsten Wartmann c...@blenderbuch.de wrote: Am 19.02.2011 16:22, schrieb Morten Mikkelsen: Hi all, Blender is exporting normal maps with red and green channel inverted relative to the geometry we actually export with our exporters and I would very much like to fix this. This would make blender export normal maps which are very similar to most tools out there and it would make sense to people trying to use them in their own engines. Good! It will be different from maps baked with blender previously but then that This does mean that old scenes render incorrect? Just to clarify. Or will there be some compatibility switch? Carsten Kaito has asked me to ask you guys if you are ok with it? Who's that guy hanging around there all the time? ;-) -- Carsten Wartmann: Autor - Dozent - 3D - Grafik Homepage: http://blenderbuch.de/ Das Blender-Buch: http://blenderbuch.de/redirect.html ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Fluid particles refactoring
Hi :) Sounds great! I am just at particles chapter for my book an was not sure to include fluid particles at all, it is (was?) quite hard to get nice simulations, they tend to explode to often with no (for me) obvious reason. That explode thing is long in the past, Jahka has improved a lo the stability so now is pretty easy to get nice simulations However, I have not so much real use for them until we have a mesh tesselation for them. Suggestions welcome. Is on the way ;) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Fluid particles refactoring
On 19.2.2011, at 20.20, ra...@info.upr.edu.cu wrote: Is on the way ;) This comment really made my day =D Thanks. -mats ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Soft Limits for Constraints?
Currently we have some limiting constraints. All have hard limits. That means there will be no interaction until the limit has been reached. But as soon the limit is reached it will have full impact. For organic models it results in not fluid motion. As this constraints are in comparison to others very simple (especially 'limit distance' and 'floor'), wouldn't it a great option to give them a second distance or offset that the constraint already starts working if the secondary distance is reached? Slowly (linear/cubic) getting more influence until the original limit will take full effect. The result would be a smooth blending between unconstrained and fully constrained state. My typical ball example: The ball is the constraint object/bone, while the wall is the limit. Throwing the ball through the wall would softly start to stop him, before he reaches the surface of the wall. As he hits the wall, he will be fully constrained as usual. Without a secondary limit the ball would fly at full speed until it hits and stop immediately. Is someone willing to implement this (optional) feature for this kind of constraints? Or does it not make sense since it could be done in a other way? Greetings from Tobias Oelgarte ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Fluid particles refactoring
Am 19.02.2011 19:20, schrieb ra...@info.upr.edu.cu: Hi :) Sounds great! I am just at particles chapter for my book an was not sure to include fluid particles at all, it is (was?) quite hard to get nice simulations, they tend to explode to often with no (for me) obvious reason. That explode thing is long in the past, Jahka has improved a lo the stability so now is pretty easy to get nice simulations I always use a daily build. So completely it is not past... However, I have not so much real use for them until we have a mesh tesselation for them. Suggestions welcome. Is on the way ;) Great, but I guess too late for my book. So far it is usefull for such kind of stuff: http://www.youtube.com/watch?v=U_azkgb5mXM ;-) Carsten -- Carsten Wartmann: Autor - Dozent - 3D - Grafik Homepage: http://blenderbuch.de/ Das Blender-Buch: http://blenderbuch.de/redirect.html ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] normal maps, red/green channel inverted
I wonder if instead of a commandline it would be possible to do this conversion with Python. I'm not sure of the current status of bpy for image handling, but it would be neat to have an addon for that. my 2 cents, Dalai 2011/2/19 Morten Mikkelsen mikkels...@gmail.com: This does mean that old scenes render incorrect? Just to clarify. Or will there be some compatibility switch? Mario (lmg) suggests we'll throw in a commandline for how to do batch convert in image magic. The inversion we're talking about corresponds to ctrl+i in photoshop btw. It's essentially (in 8 bit): val_new = 255 - val_cur; applied to red and green. This will make the normals stored in the map correspond to tangent space generated from the geometry we actually export in all of our exporters. Like I said since we have already done an overhaul on how normal maps work to get them to work properly and support mirroring, face/face verts order-independence, welding independence etc. We might as well be sure to get it right now. Seems like now or never, And this is a small adjustment on the change that is already in anyway. Cheers, Morten. On Sat, Feb 19, 2011 at 7:51 AM, Carsten Wartmann c...@blenderbuch.de wrote: Am 19.02.2011 16:22, schrieb Morten Mikkelsen: Hi all, Blender is exporting normal maps with red and green channel inverted relative to the geometry we actually export with our exporters and I would very much like to fix this. This would make blender export normal maps which are very similar to most tools out there and it would make sense to people trying to use them in their own engines. Good! It will be different from maps baked with blender previously but then that This does mean that old scenes render incorrect? Just to clarify. Or will there be some compatibility switch? Carsten Kaito has asked me to ask you guys if you are ok with it? Who's that guy hanging around there all the time? ;-) -- Carsten Wartmann: Autor - Dozent - 3D - Grafik Homepage: http://blenderbuch.de/ Das Blender-Buch: http://blenderbuch.de/redirect.html ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] normal maps, red/green channel inverted
Am 19.02.2011 23:08, schrieb Dalai Felinto: I wonder if instead of a commandline it would be possible to do this conversion with Python. I'm not sure of the current status of bpy for image handling, but it would be neat to have an addon for that. My idea was having a Button inside the Texture Context, Image Tab (beneath the Normal Map Button) to use old Blender Normal maps. Carsten -- Carsten Wartmann: Autor - Dozent - 3D - Grafik Homepage: http://blenderbuch.de/ Das Blender-Buch: http://blenderbuch.de/redirect.html ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Inverse Shrinkwrap? (only keep above surface)
Here is a rig I did that has full body muscle simulation (or sort of) made with shrinkwrap. It's blender 2.49. I had to use nearest surface point in most cases, combined with a subsurf modifier in each muscle object. The feature Campbell agreed to do would be cool, but in my opinion, if we are talking of complex surfaces, the shrinkwrap modifier needs a full refactoring and I don't know if there is any dev willing to that at this moment... Date: Sat, 19 Feb 2011 14:42:32 +0100 From: tobias.oelga...@googlemail.com To: bf-committers@blender.org Subject: Re: [Bf-committers] Inverse Shrinkwrap? (only keep above surface) If you reduce the offset to 0.0 then the problem is not visible. It only happens with offset different from 0. Offset is ignored, until original mesh, without offset, is reached. Am 19.02.2011 14:24, schrieb Tobias Oelgarte: Currently i did some tests and it shows that the behavior of projection and and nearest surface point is way different. Projection also makes the vertices jumping. I tested it with svn rev34989 and appended an very simple example. Just use the shapekey-slider (Key 1) of the red inner object (something like a muscle) and you will see that the skin is snapping. First nothing, then a jump, followed by a smooth further transition. That is unacceptable for muscles and in many complex cases even worse. Example file: http://www.pasteall.org/blend/5290 Am 19.02.2011 10:16, schrieb Campbell Barton: Found this can be done already (sort of), Project negative then cull front or back. There was a bug where rotating the object made culling fail, fixed r34986. This works ok with a sphere/cube and sphere/plane so in real usage there may be some other options needed. If this isn't working well I'd be interested to see an example blend file. On Fri, Feb 18, 2011 at 8:02 PM, Daniel Salazar - 3Developer.com zan...@gmail.com wrote: Thumbs up for suggestion. For group behavior lets just wait for nodal modifiers, this will be a no brainer with a forgroup loop node cheers Daniel Salazar 2011/2/18ra...@info.upr.edu.cu: Hi May be my recent released relaxation patch can help http://www.box.net/shared/ddhtfnsq75 HI guys! As I see it, shrinkwrap is lacking of two things that would make it even better. 1_ A Neighboring vertexes smoothing factor. This would be done by applying a kind of falloff to the affected surface like in these examples: http://chrisevans3d.com/tutorials/maya_muscle.htm 2_ An algorithm that determines that if a vertex movement goes out of a certain distance range, those vertexes should be smooth out or its movement averaged with the movement of the neighboring vertexes. This feature could avoid vertex artifacts with an articulated object, specially in projection mode. Maybe this is too much to ask from Campbell's weekend quick fix, but you never know when Jaguarandi is reading :p Date: Fri, 18 Feb 2011 14:26:55 +0100 From: tobias.oelga...@googlemail.com To: bf-committers@blender.org Subject: Re: [Bf-committers] Inverse Shrinkwrap? (only keep above surface) Using a group of objects could be useful, but if it's not done for multiple objects, you still can just apply multiple shrinkwraps in keep above only mode to achieve more or less the same result. In many cases it would be just one collision object and fine. Of course groups of objects would move the vertices more correctly. But as you said: One step at a time. The first one alone would already be great. Am 18.02.2011 14:14, schrieb Campbell Barton: You're right that this is simple to add and agree it seems very useful, quick way to reducing intersections without physics errors. The main downside I can see, as the verts slide over large variance it could give visible popping in some cases, though this is no difference then shrink-wrap for other uses. Though it makes me think for this feature it would be even more useful in production is if the modifier could select a group of objects to 'not pass through', rather then a single one. But one thing at a time, this seems reasonable and if theres no objections I can add this over the weekend since I made some changes to this area recently. On Fri, Feb 18, 2011 at 12:43 PM, Tobias Oelgarte tobias.oelga...@googlemail.comwrote: Shrinkwrap is designed to force vertices onto the surface of another object. In Nearest Surfacepoint mode it moves vertices either to the surface or optionally let it also move outward until they are on the surface. So you can work with essential two options. But wouldn't it make more sense to include also the possibility that vertices can also only be moved up onto the surface and and not moved toward it? It would allow you to throw a ball against a window, making the vertices
Re: [Bf-committers] Inverse Shrinkwrap? (only keep above surface)
I Forgot to copy the link to the rig :p http://www.zshare.net/download/60908072098fa1ae/ http://www.jpbouza.com.ar/ESP2/descargas/blenrig-3/ From: jpbo...@hotmail.com To: bf-committers@blender.org Date: Sat, 19 Feb 2011 22:04:54 -0300 Subject: Re: [Bf-committers] Inverse Shrinkwrap? (only keep above surface) Here is a rig I did that has full body muscle simulation (or sort of) made with shrinkwrap. It's blender 2.49. I had to use nearest surface point in most cases, combined with a subsurf modifier in each muscle object. The feature Campbell agreed to do would be cool, but in my opinion, if we are talking of complex surfaces, the shrinkwrap modifier needs a full refactoring and I don't know if there is any dev willing to that at this moment... Date: Sat, 19 Feb 2011 14:42:32 +0100 From: tobias.oelga...@googlemail.com To: bf-committers@blender.org Subject: Re: [Bf-committers] Inverse Shrinkwrap? (only keep above surface) If you reduce the offset to 0.0 then the problem is not visible. It only happens with offset different from 0. Offset is ignored, until original mesh, without offset, is reached. Am 19.02.2011 14:24, schrieb Tobias Oelgarte: Currently i did some tests and it shows that the behavior of projection and and nearest surface point is way different. Projection also makes the vertices jumping. I tested it with svn rev34989 and appended an very simple example. Just use the shapekey-slider (Key 1) of the red inner object (something like a muscle) and you will see that the skin is snapping. First nothing, then a jump, followed by a smooth further transition. That is unacceptable for muscles and in many complex cases even worse. Example file: http://www.pasteall.org/blend/5290 Am 19.02.2011 10:16, schrieb Campbell Barton: Found this can be done already (sort of), Project negative then cull front or back. There was a bug where rotating the object made culling fail, fixed r34986. This works ok with a sphere/cube and sphere/plane so in real usage there may be some other options needed. If this isn't working well I'd be interested to see an example blend file. On Fri, Feb 18, 2011 at 8:02 PM, Daniel Salazar - 3Developer.com zan...@gmail.com wrote: Thumbs up for suggestion. For group behavior lets just wait for nodal modifiers, this will be a no brainer with a forgroup loop node cheers Daniel Salazar 2011/2/18ra...@info.upr.edu.cu: Hi May be my recent released relaxation patch can help http://www.box.net/shared/ddhtfnsq75 HI guys! As I see it, shrinkwrap is lacking of two things that would make it even better. 1_ A Neighboring vertexes smoothing factor. This would be done by applying a kind of falloff to the affected surface like in these examples: http://chrisevans3d.com/tutorials/maya_muscle.htm 2_ An algorithm that determines that if a vertex movement goes out of a certain distance range, those vertexes should be smooth out or its movement averaged with the movement of the neighboring vertexes. This feature could avoid vertex artifacts with an articulated object, specially in projection mode. Maybe this is too much to ask from Campbell's weekend quick fix, but you never know when Jaguarandi is reading :p Date: Fri, 18 Feb 2011 14:26:55 +0100 From: tobias.oelga...@googlemail.com To: bf-committers@blender.org Subject: Re: [Bf-committers] Inverse Shrinkwrap? (only keep above surface) Using a group of objects could be useful, but if it's not done for multiple objects, you still can just apply multiple shrinkwraps in keep above only mode to achieve more or less the same result. In many cases it would be just one collision object and fine. Of course groups of objects would move the vertices more correctly. But as you said: One step at a time. The first one alone would already be great. Am 18.02.2011 14:14, schrieb Campbell Barton: You're right that this is simple to add and agree it seems very useful, quick way to reducing intersections without physics errors. The main downside I can see, as the verts slide over large variance it could give visible popping in some cases, though this is no difference then shrink-wrap for other uses. Though it makes me think for this feature it would be even more useful in production is if the modifier could select a group of objects to 'not pass through', rather then a single one. But one thing at a time, this seems reasonable and if theres no objections I can add this over the weekend since I made some changes to this area recently. On Fri, Feb 18, 2011 at 12:43 PM, Tobias Oelgarte tobias.oelga...@googlemail.comwrote: Shrinkwrap is designed to force vertices onto the surface of another
Re: [Bf-committers] MinGW debug builds do not run
Whats supported isn't set in stone, its more a case of which configurations are tested known to work. this works for me. - windows xp - mingw-gcc4.5.2, (from mingw's main site) - cmake 2.8 (build type set to Release or RelWithDebInfo) - blender (tested r34959) A crash on startup may be a real bug rather then lack of support, you could run with gdb and see why its crashing. If you are unable to figure out how to fix you could file a bug and include a backtace. Another way to help find the cause of the crash is to disable all WITH_* options in cmake configuration, WITH_OPENAL, WITH_IMAGE_OPENEXR ... etc. If this works you could try again with usable settings (so you get an interface), all off except WITH_PYTHON WITH_INSTALL and WITH_PYTHON_INSTALL. After that its trial and error to see which library causes the crash, the offending lib could be disabled by default with mingw until its fixed properly. One other thing, you were getting the error 'PyModule_Create2' interestingly I got this error too on Linux when trying to load a library built with a debug python but finding a release library. On Sat, Feb 19, 2011 at 3:26 PM, Peter Kümmel syntheti...@gmx.net wrote: Tested it with cmake too. It links after a small fix, but crashes immediately after starting. Seems mingw isn't supported. Peter ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [34914] trunk/blender/release/scripts/ui/ properties_material.py: Commit patch [#25939] material panel proposal by Ervin Weber (lu
Any final word on whether this will be reverted or not? If the commit is here to stay I think for BGE we will need some changes. -- Dalai # -- Re: New Render Pipeline Panel # ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
