Re: [Bf-committers] Substituting hot keys in an addon
On 16/06/11 06:46, Nathan Vegdahl wrote: > Hello all, > I am wondering if there is a best practice for substituting hotkeys > via an addon. > > The use-case is that in Rigify I would like to allow the user to > add rig-type samples via shift-A in armature edit mode. Doing so will > require popping up a menu of some kind. However, currently shift-A in > armature edit mode does not produce a menu, and instead immediately > calls the bone_primitive_add operator, so I cannot simply insert items > into the non-existent menu. > > What I would like to do is substitute in a menu when the Rigify > addon is enabled. I am curious if there is an accepted best-practice > way to do this, that is robust against custom keymaps, for example, > and other corner-cases. Should I just search the active keymap for > the bone_primitive_add operator, and substitute in my own? That seems > like it could potentially cause problems. > > Alternatively I could make vanilla Blender produce a menu, and then > simply insert my own items into the menu when rigify is enabled. > Would that be a better way to go about it? > > --Nathan > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers why don't you look at how dynamic spacebar addon does it ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Substituting hot keys in an addon
On Thu, Jun 16, 2011 at 7:22 AM, Michael Fox wrote: > On 16/06/11 06:46, Nathan Vegdahl wrote: >> Hello all, >> I am wondering if there is a best practice for substituting hotkeys >> via an addon. >> >> The use-case is that in Rigify I would like to allow the user to >> add rig-type samples via shift-A in armature edit mode. Doing so will >> require popping up a menu of some kind. However, currently shift-A in >> armature edit mode does not produce a menu, and instead immediately >> calls the bone_primitive_add operator, so I cannot simply insert items >> into the non-existent menu. >> >> What I would like to do is substitute in a menu when the Rigify >> addon is enabled. I am curious if there is an accepted best-practice >> way to do this, that is robust against custom keymaps, for example, >> and other corner-cases. Should I just search the active keymap for >> the bone_primitive_add operator, and substitute in my own? That seems >> like it could potentially cause problems. >> >> Alternatively I could make vanilla Blender produce a menu, and then >> simply insert my own items into the menu when rigify is enabled. >> Would that be a better way to go about it? >> >> --Nathan >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers > why don't you look at how dynamic spacebar addon does it Dynamic spacebar is certainly not best practice since making reloading the defaults (Ctrl+N), clears the key binding. This isn't really the fault of the scripts author, we just don't have a good way to do this yet. -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] SVN commit: /data/svn/bf-blender [37537] branches/soc-2011-pepper: == Simple Title Cards for Sequencer ==
Hi Algorith, don't you think, we should add some other extensions to blender, that make it possible, to script something like this with Python? Problem is: you wrote a *very* special solution for a very special problem you had, and I'd like to keep the sequencer core clean and simple. Would be cool, if you could specify a SCENE as template and only fill in parameters. Add some tweaks to the SCENE strip, that make it optionally render to files by default, add template parameters for the SCENE strip and there we go. Then your title cards will end up as ONE additional scene as template and template parameters to edit within the strip. That is in the long run a much better solution, since you give people the freedom to make title cards or even fancy title cards as they like. You can add a Python script, that wraps this all nicely, so that you can add some default title cards / whatever. (Which could add a template SCENE automagically.) BTW: I personally use additional scenes within the same file, length 1, which get extruded and animated properly. That way, the SCENE is rendered once into the memory cache and the cached result is animated (with fades etc.) If I didn't get the problem correctly, just let me know. I really like to work out a generic solution for that! Cheers, Peter Peter Schlaile ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] SVN commit: /data/svn/bf-blender [37537] branches/soc-2011-pepper: == Simple Title Cards for Sequencer ==
Hey Peter, Cheers for the feedback! Indeed, as I started to pick through things, the issues faced by users who would want to use this as a base on which to start extending it in some ways did come up. Sure, a script which sets up a generic template would be nice in this situation, and is one way I'd thought of doing it. Some factors which made me favour this approach though were that: 1) Using this approach, we let automation take over making sure that the text fits and is aligned nicely in frame when things change. From experience, I've ended up scaling and re scaling text, moving it all over the place trying to get it to fit and be in frame. Registering a special operator for this, and/or trying to find somewhere decent to put it so that it can be easily found is an issue. 2) Text colours can be set in one place with this method, without fudging with material settings (and doing material-unlink dances after copying some text and deciding you want it a different colour - then again here, the level of control over this stuff is entirely hardcoded) 3) AFAIK, scene strips were synonymous with constantly being re-rendered and re-evaluated every single time they're encountered, when doing scene evaluation combined with rendering is a comparatively sluggish process for Blender. The alternative would have been to force people to always render these out to image files (something that I'm trying to avoid here) before they could be used. (*1) 4) With this approach, including text in the sequencer feels more like a "first-class" entity than just a weirdo heavy-duty workflow, where you have a proliferation of "scene" strips in your timeline which are essentially just there to display text (but outwardly don't communicate this) 5) There's also the issue of a buildup of scene files in the file, each one for a different slide, making it easy to accidentally delete the wrong one from the file, and also making it slower to find the scene to go in and edit its text. (*2) - (*1) From your mail below, it sounds like that's something the cache voodoo might be able to take care of under certain circumstances. As only a very infrequent user of VSE, I wasn't aware of this. (*2) I'm not really convinced about the idea of these template parameters for the scene strips. It sounds even more like a specialised hack from user perspective than shoehorning an entire strip type with some predefined slots where people commonly place text for common purposes. --- Anyhow, as an "experimental" feature, this was certainly a good exercise for seeing how such functionality could look like, and to generate debate over what use cases for this sort of stuff users have. (It was also a good exercise in exploring how the sequencer works, though I might add that the number of places where you have to redefine how a new strip type is a bit excessive) Personally, this is probably sufficient, though maybe with a few more optional slots for text. If nothing else, I can now save off this build for future use where necessary ;) Perhaps as you suggest, an operator which generates some preset title-card scene setups would be handy to have. Though it's the details of how we allow people to tweak the content there which worries me a bit. Regards, Joshua On Thu, Jun 16, 2011 at 10:35 PM, Peter Schlaile wrote: > Hi Algorith, > > don't you think, we should add some other extensions to > blender, that make it possible, to script something like this with Python? > > Problem is: you wrote a *very* special solution for a > very special problem you had, and I'd like to keep the > sequencer core clean and simple. > > Would be cool, if you could specify a SCENE as template and only fill in > parameters. > > Add some tweaks to the SCENE strip, that make it optionally render to > files by default, add template parameters for the SCENE strip and there > we go. > > Then your title cards will end up as ONE additional scene as template and > template parameters to edit within the strip. > > That is in the long run a much better solution, since you give people the > freedom to make title cards or even fancy title cards as they like. > > You can add a Python script, that wraps this all nicely, so that you can > add some default title cards / whatever. (Which could add a template SCENE > automagically.) > > BTW: I personally use additional scenes within the same file, length 1, > which get extruded and animated properly. That way, the SCENE is rendered > once into the memory cache and the cached result is animated (with fades > etc.) > > If I didn't get the problem correctly, just let me know. I really like to > work out a generic solution for that! > > Cheers, > Peter > > > Peter Schlaile > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-
[Bf-committers] Siggraph presentations + tickets
Hi all, Here's an overview of Blender related events at Siggraph, Vanvouver, 7-11 August. http://www.blender.org/news/article/blender-foundation-at-siggraph/ There's going to be a Blender booth! For free tradeshow tickets you can mail me anytime. Laters, -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Limits ignored for last bone of IK-chain?
In recent time I had to do with multiple rigs for figures. One thing that often caused me problems are the limits for bones of IK-chains. While the limits for the bones inside the chain are respected by the solver, the limits of the last bone of such a chain is always ignored. I searched inside the documentations and could not find a reason why it acts like this, or how to avoid this behaviour. It would make sense in many cases, but it does not work that way. Do you have a suggestion how to handle this problem in a way that the last bone of the chain also respects it's limits or at least some kind of workaround? Would be very helpful. Best Wishes Tobias Oelgarte ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Substituting hot keys in an addon
Okay, it sounds like there isn't really a nice way to do this yet, then. So I'll change vanilla Blender to pop up a menu on shift-A. That should be useful for other addons involving armatures as well. --Nathan On Thu, Jun 16, 2011 at 1:46 AM, Campbell Barton wrote: > On Thu, Jun 16, 2011 at 7:22 AM, Michael Fox wrote: >> On 16/06/11 06:46, Nathan Vegdahl wrote: >>> Hello all, >>> I am wondering if there is a best practice for substituting hotkeys >>> via an addon. >>> >>> The use-case is that in Rigify I would like to allow the user to >>> add rig-type samples via shift-A in armature edit mode. Doing so will >>> require popping up a menu of some kind. However, currently shift-A in >>> armature edit mode does not produce a menu, and instead immediately >>> calls the bone_primitive_add operator, so I cannot simply insert items >>> into the non-existent menu. >>> >>> What I would like to do is substitute in a menu when the Rigify >>> addon is enabled. I am curious if there is an accepted best-practice >>> way to do this, that is robust against custom keymaps, for example, >>> and other corner-cases. Should I just search the active keymap for >>> the bone_primitive_add operator, and substitute in my own? That seems >>> like it could potentially cause problems. >>> >>> Alternatively I could make vanilla Blender produce a menu, and then >>> simply insert my own items into the menu when rigify is enabled. >>> Would that be a better way to go about it? >>> >>> --Nathan >>> ___ >>> Bf-committers mailing list >>> Bf-committers@blender.org >>> http://lists.blender.org/mailman/listinfo/bf-committers >> why don't you look at how dynamic spacebar addon does it > > Dynamic spacebar is certainly not best practice since making reloading > the defaults (Ctrl+N), clears the key binding. > This isn't really the fault of the scripts author, we just don't have > a good way to do this yet. > > -- > - Campbell > ___ > 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] Smooth shading could be better (compared to C4D)
Today I received a model as an .obj file from Cinema4D to continue working on it, while my workmate is on vacation. It turned out that the smooth shading in Blender highlights/shows shading artifacts due to toplogy (like poles) a lot more than Cinema4D does. Also beveled edges and corners are displayed a lot smoother in C4D. Maybe someone can look into this? Kind regards, Andreas Galster ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Smooth shading could be better (compared to C4D)
would be good to provide a few screenshots so people can see what blender does and what you would like it to do. LetterRip On Thu, Jun 16, 2011 at 12:16 PM, Andreas Galster wrote: > > Today I received a model as an .obj file from Cinema4D to continue working on > it, while my workmate is on vacation. It turned out that the smooth shading > in Blender highlights/shows shading artifacts due to toplogy (like poles) a > lot more than Cinema4D does. > Also beveled edges and corners are displayed a lot smoother in C4D. Maybe > someone can look into this? > > Kind regards, > Andreas Galster > > ___ > 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] SVN commit: /data/svn/bf-blender [37537] branches/soc-2011-pepper: == Simple Title Cards for Sequencer ==
Personally, I think a text strip has been sorely missing from the sequencer (and compositor) for a while, and it's great to see it added. Doing it via blender scenes and python is a really slow, nasty overcomplicated way of doing something which really should be quite simple, and is a really simple, common, basic tool in most other editors. Editing the text from the sequence editor interface and having it rendered directly to a strip is the fastest and best way of having such a feature, and it's something I would have loved to have had plenty of times. Note: I haven't tried the current patch but it would be best as a generalised 'text strip' rather than anything aimed specifically at title cards, with properties like text box height and width, and typographic/paragraph controls too. cheers Matt On Thu, Jun 16, 2011 at 9:26 PM, Joshua Leung wrote: > Hey Peter, > > Cheers for the feedback! > > Indeed, as I started to pick through things, the issues faced by users > who would want to use this as a base on which to start extending it in > some ways did come up. Sure, a script which sets up a generic template > would be nice in this situation, and is one way I'd thought of doing > it. > > Some factors which made me favour this approach though were that: > 1) Using this approach, we let automation take over making sure that > the text fits and is aligned nicely in frame when things change. From > experience, I've ended up scaling and re scaling text, moving it all > over the place trying to get it to fit and be in frame. Registering a > special operator for this, and/or trying to find somewhere decent to > put it so that it can be easily found is an issue. > > 2) Text colours can be set in one place with this method, without > fudging with material settings (and doing material-unlink dances after > copying some text and deciding you want it a different colour - then > again here, the level of control over this stuff is entirely > hardcoded) > > 3) AFAIK, scene strips were synonymous with constantly being > re-rendered and re-evaluated every single time they're encountered, > when doing scene evaluation combined with rendering is a comparatively > sluggish process for Blender. The alternative would have been to force > people to always render these out to image files (something that I'm > trying to avoid here) before they could be used. (*1) > > 4) With this approach, including text in the sequencer feels more like > a "first-class" entity than just a weirdo heavy-duty workflow, where > you have a proliferation of "scene" strips in your timeline which are > essentially just there to display text (but outwardly don't > communicate this) > > 5) There's also the issue of a buildup of scene files in the file, > each one for a different slide, making it easy to accidentally delete > the wrong one from the file, and also making it slower to find the > scene to go in and edit its text. (*2) > > - > > (*1) From your mail below, it sounds like that's something the cache > voodoo might be able to take care of under certain circumstances. As > only a very infrequent user of VSE, I wasn't aware of this. > > (*2) I'm not really convinced about the idea of these template > parameters for the scene strips. It sounds even more like a > specialised hack from user perspective than shoehorning an entire > strip type with some predefined slots where people commonly place text > for common purposes. > > --- > > Anyhow, as an "experimental" feature, this was certainly a good > exercise for seeing how such functionality could look like, and to > generate debate over what use cases for this sort of stuff users have. > (It was also a good exercise in exploring how the sequencer works, > though I might add that the number of places where you have to > redefine how a new strip type is a bit excessive) > > Personally, this is probably sufficient, though maybe with a few more > optional slots for text. If nothing else, I can now save off this > build for future use where necessary ;) > > Perhaps as you suggest, an operator which generates some preset > title-card scene setups would be handy to have. Though it's the > details of how we allow people to tweak the content there which > worries me a bit. > > Regards, > Joshua > > On Thu, Jun 16, 2011 at 10:35 PM, Peter Schlaile > wrote: > > Hi Algorith, > > > > don't you think, we should add some other extensions to > > blender, that make it possible, to script something like this with > Python? > > > > Problem is: you wrote a *very* special solution for a > > very special problem you had, and I'd like to keep the > > sequencer core clean and simple. > > > > Would be cool, if you could specify a SCENE as template and only fill in > > parameters. > > > > Add some tweaks to the SCENE strip, that make it optionally render to > > files by default, add template parameters for the SCENE strip and there > > we go. > > > > Then your title cards will end up as ONE additi
Re: [Bf-committers] Smooth shading could be better (compared to C4D)
We'd also need to know if normals are coming over with the .obj or are they being calculated once inside Blender? On Thu, Jun 16, 2011 at 3:54 PM, Tom M wrote: > would be good to provide a few screenshots so people can see what > blender does and what you would like it to do. > > LetterRip > > On Thu, Jun 16, 2011 at 12:16 PM, Andreas Galster > wrote: >> >> Today I received a model as an .obj file from Cinema4D to continue working >> on it, while my workmate is on vacation. It turned out that the smooth >> shading in Blender highlights/shows shading artifacts due to toplogy (like >> poles) a lot more than Cinema4D does. >> Also beveled edges and corners are displayed a lot smoother in C4D. Maybe >> someone can look into this? >> >> Kind regards, >> Andreas Galster >> >> ___ >> 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] Smooth shading could be better (compared to C4D)
http://artworkforge.com/blender-smooth.jpg http://artworkforge.com/c4d-smooth.jpg With beveled corners C4D is definitely the winner. See the star like shading in Blender? Not very pretty. At the flat area C4D is displaying it a little bit better. But in general C4D is displaying this better. The model I received from my workmate (can't show) has some really ugly artifcts in Blender, whereas you can' or barely can see them in C4D. PS: Both edge split behaviours have been set to the same value of 80 (although this doesn't really matter with this model). Andreas Galster > Date: Thu, 16 Jun 2011 12:54:05 -0800 > From: letter...@gmail.com > To: bf-committers@blender.org > Subject: Re: [Bf-committers] Smooth shading could be better (compared to C4D) > > would be good to provide a few screenshots so people can see what > blender does and what you would like it to do. > > LetterRip > > On Thu, Jun 16, 2011 at 12:16 PM, Andreas Galster > wrote: > > > > Today I received a model as an .obj file from Cinema4D to continue working > > on it, while my workmate is on vacation. It turned out that the smooth > > shading in Blender highlights/shows shading artifacts due to toplogy (like > > poles) a lot more than Cinema4D does. > > Also beveled edges and corners are displayed a lot smoother in C4D. Maybe > > someone can look into this? > > > > Kind regards, > > Andreas Galster > > > > ___ > > 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] Smooth shading could be better (compared to C4D)
What do you mean? Both C4D's and Blender's normals are pointing in the same direction. Not sure how much vertex normals affect this, but I'm not aware of any way to check vertex normals in C4D. Could it be that Cinema4D is using Phong-Shading and Blender is using Gouraud-Shading? > Date: Thu, 16 Jun 2011 16:53:36 -0500 > From: xgl.asyl...@gmail.com > To: bf-committers@blender.org > Subject: Re: [Bf-committers] Smooth shading could be better (compared to C4D) > > We'd also need to know if normals are coming over with the .obj or are > they being calculated once inside Blender? > > On Thu, Jun 16, 2011 at 3:54 PM, Tom M wrote: > > would be good to provide a few screenshots so people can see what > > blender does and what you would like it to do. > > > > LetterRip > > > > On Thu, Jun 16, 2011 at 12:16 PM, Andreas Galster > > wrote: > >> > >> Today I received a model as an .obj file from Cinema4D to continue working > >> on it, while my workmate is on vacation. It turned out that the smooth > >> shading in Blender highlights/shows shading artifacts due to toplogy (like > >> poles) a lot more than Cinema4D does. > >> Also beveled edges and corners are displayed a lot smoother in C4D. Maybe > >> someone can look into this? > >> > >> Kind regards, > >> Andreas Galster > >> > >> ___ > >> 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
Re: [Bf-committers] Smooth shading could be better (compared to C4D)
>Could it be that Cinema4D is using Phong-Shading and Blender is using Gouraud-Shading? Yes that's exactly what you're seeing. You can switch to glsl view if you want to view it in Blender with per pixel lighting. Regular 3D view has to remain fixed function rendering pipeline which implies Gouraud shading. I'd argue there's nothing to look into here (no mystery). Cheers, Morten. On Thu, Jun 16, 2011 at 3:07 PM, Andreas Galster wrote: > > What do you mean? Both C4D's and Blender's normals are pointing in the same > direction. Not sure how much vertex normals affect this, but I'm not aware > of any way to check vertex normals in C4D. > Could it be that Cinema4D is using Phong-Shading and Blender is using > Gouraud-Shading? > > > Date: Thu, 16 Jun 2011 16:53:36 -0500 > > From: xgl.asyl...@gmail.com > > To: bf-committers@blender.org > > Subject: Re: [Bf-committers] Smooth shading could be better (compared to > C4D) > > > > We'd also need to know if normals are coming over with the .obj or are > > they being calculated once inside Blender? > > > > On Thu, Jun 16, 2011 at 3:54 PM, Tom M wrote: > > > would be good to provide a few screenshots so people can see what > > > blender does and what you would like it to do. > > > > > > LetterRip > > > > > > On Thu, Jun 16, 2011 at 12:16 PM, Andreas Galster > > > wrote: > > >> > > >> Today I received a model as an .obj file from Cinema4D to continue > working on it, while my workmate is on vacation. It turned out that the > smooth shading in Blender highlights/shows shading artifacts due to toplogy > (like poles) a lot more than Cinema4D does. > > >> Also beveled edges and corners are displayed a lot smoother in C4D. > Maybe someone can look into this? > > >> > > >> Kind regards, > > >> Andreas Galster > > >> > > >> ___ > > >> 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
Re: [Bf-committers] Smooth shading could be better (compared to C4D)
I think Morten is right. However, I agree that the default blender viewport shading is a bit "weaker" compared to some other packages, e.g. Maya. It is possible to approach the same look you get in the default Maya viewport, however, by adjusting the GLSL lights in the preferences. On Fri, Jun 17, 2011 at 12:57 PM, Morten Mikkelsen wrote: > >Could it be that Cinema4D is using Phong-Shading and Blender is using > Gouraud-Shading? > > Yes that's exactly what you're seeing. You can switch to glsl view if you > want to view it in Blender with per pixel lighting. > Regular 3D view has to remain fixed function rendering pipeline which > implies Gouraud shading. > I'd argue there's nothing to look into here (no mystery). > > Cheers, > > Morten. > > > > > On Thu, Jun 16, 2011 at 3:07 PM, Andreas Galster < > andreas_gals...@hotmail.de > > wrote: > > > > > What do you mean? Both C4D's and Blender's normals are pointing in the > same > > direction. Not sure how much vertex normals affect this, but I'm not > aware > > of any way to check vertex normals in C4D. > > Could it be that Cinema4D is using Phong-Shading and Blender is using > > Gouraud-Shading? > > > > > Date: Thu, 16 Jun 2011 16:53:36 -0500 > > > From: xgl.asyl...@gmail.com > > > To: bf-committers@blender.org > > > Subject: Re: [Bf-committers] Smooth shading could be better (compared > to > > C4D) > > > > > > We'd also need to know if normals are coming over with the .obj or are > > > they being calculated once inside Blender? > > > > > > On Thu, Jun 16, 2011 at 3:54 PM, Tom M wrote: > > > > would be good to provide a few screenshots so people can see what > > > > blender does and what you would like it to do. > > > > > > > > LetterRip > > > > > > > > On Thu, Jun 16, 2011 at 12:16 PM, Andreas Galster > > > > wrote: > > > >> > > > >> Today I received a model as an .obj file from Cinema4D to continue > > working on it, while my workmate is on vacation. It turned out that the > > smooth shading in Blender highlights/shows shading artifacts due to > toplogy > > (like poles) a lot more than Cinema4D does. > > > >> Also beveled edges and corners are displayed a lot smoother in C4D. > > Maybe someone can look into this? > > > >> > > > >> Kind regards, > > > >> Andreas Galster > > > >> > > > >> ___ > > > >> 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 > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Smooth shading could be better (compared to C4D)
Ah, I see. However, you can't adjust the GLSL lights in the preferences. You need real light objects for the GLSL view to receive light. While we're talking about shading. Is there a reason while new created meshes aren't set to smooth shading + having an edge split modifier assigned on default? That's the first thing I always have to do when generating new meshes. I doubt that a lot of people need their meshes without those two settings lol. Kind regards, Andreas Galster > Date: Fri, 17 Jun 2011 14:00:10 +1200 > From: felixschlit...@gmail.com > To: bf-committers@blender.org > Subject: Re: [Bf-committers] Smooth shading could be better (compared to C4D) > > I think Morten is right. However, I agree that the default blender viewport > shading is a bit "weaker" compared to some other packages, e.g. Maya. It is > possible to approach the same look you get in the default Maya viewport, > however, by adjusting the GLSL lights in the preferences. > > On Fri, Jun 17, 2011 at 12:57 PM, Morten Mikkelsen > wrote: > > > >Could it be that Cinema4D is using Phong-Shading and Blender is using > > Gouraud-Shading? > > > > Yes that's exactly what you're seeing. You can switch to glsl view if you > > want to view it in Blender with per pixel lighting. > > Regular 3D view has to remain fixed function rendering pipeline which > > implies Gouraud shading. > > I'd argue there's nothing to look into here (no mystery). > > > > Cheers, > > > > Morten. > > > > > > > > > > On Thu, Jun 16, 2011 at 3:07 PM, Andreas Galster < > > andreas_gals...@hotmail.de > > > wrote: > > > > > > > > What do you mean? Both C4D's and Blender's normals are pointing in the > > same > > > direction. Not sure how much vertex normals affect this, but I'm not > > aware > > > of any way to check vertex normals in C4D. > > > Could it be that Cinema4D is using Phong-Shading and Blender is using > > > Gouraud-Shading? > > > > > > > Date: Thu, 16 Jun 2011 16:53:36 -0500 > > > > From: xgl.asyl...@gmail.com > > > > To: bf-committers@blender.org > > > > Subject: Re: [Bf-committers] Smooth shading could be better (compared > > to > > > C4D) > > > > > > > > We'd also need to know if normals are coming over with the .obj or are > > > > they being calculated once inside Blender? > > > > > > > > On Thu, Jun 16, 2011 at 3:54 PM, Tom M wrote: > > > > > would be good to provide a few screenshots so people can see what > > > > > blender does and what you would like it to do. > > > > > > > > > > LetterRip > > > > > > > > > > On Thu, Jun 16, 2011 at 12:16 PM, Andreas Galster > > > > > wrote: > > > > >> > > > > >> Today I received a model as an .obj file from Cinema4D to continue > > > working on it, while my workmate is on vacation. It turned out that the > > > smooth shading in Blender highlights/shows shading artifacts due to > > toplogy > > > (like poles) a lot more than Cinema4D does. > > > > >> Also beveled edges and corners are displayed a lot smoother in C4D. > > > Maybe someone can look into this? > > > > >> > > > > >> Kind regards, > > > > >> Andreas Galster > > > > >> > > > > >> ___ > > > > >> 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 > > > ___ > 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
