Page 51 of 149 FirstFirst ... 41495051525361101 ... LastLast
Results 1,001 to 1,020 of 2979
  1. #1001
    So, umm, where should one submit patches for this branch?

    Been checking out the python API and found a bunch of stuff that could be converted to getters/setters -- for example:
    Code:
    Index: source/blender/freestyle/intern/python/Interface1D/BPy_Stroke.cpp
    ===================================================================
    --- source/blender/freestyle/intern/python/Interface1D/BPy_Stroke.cpp    (revision 28935)
    +++ source/blender/freestyle/intern/python/Interface1D/BPy_Stroke.cpp    (working copy)
    @@ -405,6 +405,79 @@
         return PyLong_FromLong( self->s->strokeVerticesSize() );
     }
         
    +/*----------------------Stroke tp_getset ------------------------------------*/
    +
    +static int Stroke_tp_getset_setId( BPy_Stroke *self, PyObject *py_id, void *) {
    +
    +    if(!( BPy_Id_Check(py_id) ))  {
    +        PyErr_SetString(PyExc_TypeError, "expected an Id!");
    +        return -1;
    +    }
    +
    +    self->s->setId(*( ((BPy_Id *) py_id)->id ));
    +
    +    return 0;
    +}
    +
    +static int Stroke_tp_getset_setLength( BPy_Stroke *self, PyObject *value, void *) {
    +
    +    if(!( PyFloat_Check(value) )) {
    +        PyErr_SetString(PyExc_TypeError, "expected a float!");
    +        return -1;
    +    }
    +
    +    self->s->setLength((float)PyFloat_AsDouble(value));
    +
    +    return 0;
    +}
    +
    +PyObject *Stroke_tp_getset_getMediumType(BPy_Stroke *self, void *) {
    +    return BPy_MediumType_from_MediumType( self->s->getMediumType() );
    +}
    +
    +static int Stroke_tp_getset_setMediumType( BPy_Stroke *self, PyObject *py_mt, void *) {
    +
    +    if(!( BPy_MediumType_Check(py_mt) ))  {
    +        PyErr_SetString(PyExc_TypeError, "expected a Medium Type!");
    +        return -1;
    +    }
    +
    +    self->s->setMediumType( MediumType_from_BPy_MediumType(py_mt) );
    +
    +    return 0;
    +}
    +
    +static PyGetSetDef Stroke_getseters[] = {
    +    {(char *)"id",
    +     NULL,
    +     (setter)Stroke_tp_getset_setId,
    +     (char *)"The Id of the Stroke.",
    +     NULL},
    +    {(char *)"length",
    +     NULL,
    +     (setter)Stroke_tp_getset_setLength,
    +     (char *)"The length of the Stroke.",
    +     NULL},
    +    {(char *)"medium_type",
    +     (getter)Stroke_tp_getset_getMediumType,
    +     (setter)Stroke_tp_getset_setMediumType,
    +     (char *)"The Medium Type of this Stroke.",
    +     NULL},
    +#if 0
    +    {"texture_id",
    +     (getter)Stroke_tp_getset_getTextureId,
    +     (setter)Stroke_tp_getset_setTextureId,
    +     "The Texture Id of this Stroke.",
    +     NULL},
    +    {"tips",
    +     (getter)Stroke_tp_getset_getTips,
    +     (setter)Stroke_tp_getset_setTips,
    +     "Texture tips flag.",
    +     NULL},
    +#endif
    +    {NULL,NULL,NULL,NULL,NULL}  /* Sentinel */
    +};
    +
     /*----------------------Stroke instance definitions ----------------------------*/
     
     static PyMethodDef BPy_Stroke_methods[] = {    
    @@ -472,7 +545,7 @@
         0,                              /* tp_iternext */
         BPy_Stroke_methods,             /* tp_methods */
         0,                              /* tp_members */
    -    0,                              /* tp_getset */
    +    Stroke_getseters,               /* tp_getset */
         &Interface1D_Type,              /* tp_base */
         0,                              /* tp_dict */
         0,                              /* tp_descr_get */
    The two methods of get/set can live happily together but IMHO the get/setParameter() is more along the lines of C++ than python.

    Can also look into the iterator thing.



  2. #1002
    @manbitesdog
    You don't have to separate each object into a different render layer.
    Put them all in a single render layer and try

    Operators.select(AndUP1D(QuantitativeInvisibilityU P1D(0), pyNatureUP1D(Nature.SILHOUETTE)))

    As demonstrated by the example above, Freestyle is capable of handling a set
    of objects both separately and as a whole, as far as the capability is properly
    exploited through style modules.

    If you want to further improve the results, please feel free to ask more questions.



  3. #1003
    @mzungu
    Thank you for the comments. I fully agree that Freestyle needs an artist-frendly
    UI. I have been long considering how to put such a UI into the Freestyle framework.
    As a reference, I have in mind the UI of Pencil+, a NPR shader plug-in for 3ds Max:
    http://www.psoft.co.jp/en/product/pencil/
    Maybe something similar to this will meet a large portion of user requirements.

    What I really don't want to do is to weaken Freestyle's high programability.
    Freestyle is not only a bunch of predefined parameterized styles, but also
    intended to be a tool that allows you to define new styles based on novel
    stylization ideas and new parameters. A major requirement for a Freestyle UI
    is to keep this latter capability. This makes the design and implementation of
    the artist-friendly UI a non-trivial work. As discussed several times in the
    past, a node-based system would be an ideal UI that most people could imagine.
    IMHO, however, this approach is too ambitious if the present limited resources
    (i.e., time and developers) are taken into account.

    As an alternative idea, I have also been thinking of providing a versatile
    style module that comprises as many parameters as possible. This style module
    would not include any programability. Instead, it provides a fixed set of
    toggle buttons, sliders, menus for combining and manipulating style parameters.
    Let us consider including the following options:

    [feature edge selection: visible/invisible, nature (e.g., border, crease), 2D length, object names]
    [join rules: silhouette, same object ID, same nature]
    [stroke thickness: constant, variable, depth-dependent, depth discontinuity]
    [stroke color: constant, variable, material-based]
    [stroke modifiers: noise, tip removal, bezier curve fitting, backbone stretching]

    Combining these options will reproduce most of the standard style modules and
    give you more possibilities in a flexible manner. It is my impression that
    implementing this style module won't require too much.
    Last edited by T.K.; 03-Mar-12 at 13:55.



  4. #1004
    Member paulhart2's Avatar
    Join Date
    Feb 2008
    Location
    San Diego
    Posts
    529
    T.K. So glad to hear your ideas about UI. Retaining the underlying programmatic flexibility is certainly important, while exposing the current available parameters to easy artistic adjustment. Having a "preset" save capacity, and a "preview" window, (which Blender 2.52 has yet to include from the 2.49 version) would also help. I used to use the Parameter Editor with custom Modules before some of the code re-writes and know that it was already helpful in its primitive form. I hope that PyNodes and more surfacing options in the Compositor are also in the plan by other developers, to complement "your" lines.
    I am now able to compile successfully again. I had posted two bug reports, which may have prompted the fix, I don't know, but it is working now.
    Thank you again T.K. for your continued work and responsiveness to user input. I hope to have something to show eventually, but it always comes after "earning a living." Oh well.
    Paul
    An eye for an eye, and the whole world goes blind... Gandhi/MLKing
    Greater consciousness is worth the effort. Be aware....
    so sayest the Animated Fool. HARTWORKS http://www.hartworks.net



  5. #1005
    Member mzungu's Avatar
    Join Date
    Jul 2004
    Location
    Arkansas, USA
    Posts
    2,202
    Originally Posted by T.K. View Post
    @mzungu
    Thank you for the comments. I fully agree that Freestyle needs an artist-frendly
    UI. I have been long considering how to put such a UI into the Freestyle framework.
    I know you're aware of this need, TK. Sorry for coming on pretty strong there about this. I just really think it will help your cause tremendously when it is just made more easily accessible to less-technical users. The more "eyes" you have testing/thrashing this code, the better it will come out, I'd say.

    Originally Posted by T.K. View Post
    As an alternative idea, I have also been thinking of providing a versatile
    style module that comprises as many parameters as possible.
    Bravo! I think this is an excellent place to start. Compiling a list of "standard" parameters, categorizing them, then implementing appropriate GUI elements for each would be a treasure! (I'm guessing this is what paul's script of the past intended to accomplish.) Then, as standard parameters are added, this list (and standard style module) can simply expand to include them.

    Perhaps it could come in the form of a "style generator"? Then any "custom" parameters or code could be appended to the generated text block by those "in the know" as needed. Or provision within the generator GUI could be made for such customized parameters?

    Wish I had the skills to help. I'm very grateful for your tremendous efforts thus far. You have my thanks!
    - mzungu
    The agnostic dislexic insomniac: lies awake in bed at night wondering if there really is a dog.
    "A man convinced against his will is of the same opinion still." - Dale Carnegie



  6. #1006
    Originally Posted by T.K. View Post
    @manbitesdog
    You don't have to separate each object into a different render layer.
    Put them all in a single render layer and try

    Operators.select(AndUP1D(QuantitativeInvisibilityU P1D(0), pyNatureUP1D(Nature.SILHOUETTE)))

    As demonstrated by the example above, Freestyle is capable of handling a set
    of objects both separately and as a whole, as far as the capability is properly
    exploited through style modules.

    If you want to further improve the results, please feel free to ask more questions.
    Hi T.K., thanks for the reply. By playing around with the code you posted I can see that it must be operating on the objects independently, but I haven't been able to understand what "pyNatureUP1D(Nature.SILHOUETTE))" is actually doing (is there documentation I'm missing somewhere?). If you or someone else has time to explain it to me I'd appreciate it. Thanks!



  7. #1007
    @Uncle Entity
    Thank you for the patch. There is no standard place to where patches to the Freestyle
    branch should be sent. I think this thread is okay, and you can also sent them to me
    directly by email. If patches are too much to be put here, PasteAll.org would be useful.

    I agree that generally speaking, properties are better in Python than get/set methods.
    In the specific case of the Freestyle Python API, I feel like we need to examine the
    naming issue carefully. If you go through the API document while keep in mind the class
    hierarchy, you may identify some possible name conflicts when we move on from get/set
    methods to properties. I think I take time to investigate this before I decide to move
    on to properties. Thank you for reminding me on this matter.

    Any feedback on the iterator issue is also very welcome. Thanks.

    @manbitesdog
    In Freestyle, 0D elements (i.e., vertices) and 1D elements (e.g., edges, strokes) have
    an attribute called nature. Here is the list of available natures:

    Vertex natures:
    - Nature.POINT: True for any 0D element.
    - Nature.S_VERTEX: True for SVertex.
    - Nature.VIEW_VERTEX: True for ViewVertex.
    - Nature.NON_T_VERTEX: True for NonTVertex.
    - Nature.T_VERTEX: True for TVertex.
    - Nature.CUSP: True for CUSP.

    Edge natures:
    - Nature.NO_FEATURE: True for non feature edges (always false for 1D elements of the ViewMap).
    - Nature.SILHOUETTE: True for silhouettes.
    - Nature.BORDER: True for borders.
    - Nature.CREASE: True for creases.
    - Nature.RIDGE: True for ridges.
    - Nature.VALLEY: True for valleys.
    - Nature.SUGGESTIVE_CONTOUR: True for suggestive contours.
    - Nature.MATERIAL_BOUNDARY: True for edges at material boundaries.

    pyNatureUP1D(Nature.SILHOUETTE) returns true if an edge is a silhouette edge.
    You can specify two or more natures by joining the values with logical OR, e.g.:
    pyNatureUP1D(Nature.SILHOUETTE|Nature.BORDER)



  8. #1008
    Great, thanks T.K, I understand now how it works, and I can get the result I wanted.



    Edit: I just wanted to add I can't think of any reason to use Blender's built in Edge effect now. You can do everything it can do with freestyle, and with much finer grained control. Thumbs up to the devs!
    Last edited by manbitesdog; 27-May-10 at 18:53.



  9. #1009
    @T.K.

    Thanks for the style module demo to fix manbitesdog's issue, I've been needing that too. I cant wait till a user UI for adding such parameters is added to the freestyle branch; for now I'm using a text editior(which isnt so bad, but it would be nice). Thanks uncle entity for taking the time to share some development time on this great branch.



  10. #1010
    Member
    Join Date
    Sep 2007
    Location
    Viņa del Mar, Chile
    Posts
    1,033
    Hi, it's been a while since I saw this thread, I've been playing with Freestyle (right now version 29148) and while checking up the system monitor I found out that Freestyle doesn't seem to use threads, or at least it only uses one core of the CPU at a time.
    Check out the image:



  11. #1011
    Member
    Join Date
    Apr 2009
    Location
    New Zealand
    Posts
    228
    Large chunks of *Blender* are not multi threaded. Not every computer algorithm is capable or worth while converting to parallel code. Python itself is not really capable of being multi threaded. Once the render passes through the Freestyle section and onto the tiled rendering, your thread use should jump again.



  12. #1012
    Cloud_GL,
    Good analysis. Actually, Freestyle itself is not parallelized at all.
    More specifically, stroke rendering relies on the internal renderer,
    which is multithreaded, so that you should have a performance gain
    through the multithreaded stroke rendering. It is my impression that
    there are many other possibilities for Freestyle parallelization.
    Multithreading the view map creation by OpenMP or POSIX threads might
    lead to a good performance gain. I am interested in OpenMP and
    multithread programming, so I really hope I have enough time to work
    on Freestyle parallelization.



  13. #1013
    Member
    Join Date
    Sep 2007
    Location
    Viņa del Mar, Chile
    Posts
    1,033
    I see, at first I thought that the whole rendering process was multithreaded, that's why I asked since it seemed strange for the different performance, but thinking it twice since now, its logical because it is just one of the several passes of the renderer. I think SSS also doesn't use threading right? (at least in blender 2.49)



  14. #1014
    Member Kemmler's Avatar
    Join Date
    Mar 2007
    Location
    USA
    Posts
    1,446
    Found a way to crash freestyle repeatedly in the lastest version (got from graphicall minutes ago) (blender crashes once the freestyle pass starts)

    basically, add a cube, apply a wood texture with colorband, apply it to alpha, use shadeless, and use wire rendering, and it will crash every time.

    Not sure if this is a dumb or redundant bug report, but since it was consistent I thought I would put this out there.

    I've tested it in multiple blend files.

    I am using W7 64, but the build was unoptimized 32-bit if that matters.



  15. #1015
    I am not sure if it's ok to make requests but i think it would be really cool if this had some sort of visual preview for the styles/edge effects before rendering. By this i don't mean on the scene but a library view of all the available styles so you could quickly find the right one to apply. It would probably be fairly simple to render and make some sort of reference image though but that would be really useful in my opinion.



  16. #1016
    @Kemmler
    Thanks for the problem report. The cause of the crash was identified and fixed in the
    latest revision. It turned out that when a mesh object has a material of the wire type,
    the mesh itself is modified and passed to the renderer. The mesh modification is done
    in the way that each triangle comprising the mesh is transformed so that two of the
    three vertices are exactly in the same location. This means that the triangle is indeed
    not a face because the face normal cannot be defined. For now Freestyle only supports
    objects that have faces, so meshes with wire materials will be simply ignored and a
    warning message is displayed.

    @Cube45
    Feature requests of any kind are very welcome. In fact, a preview window has been
    requested many times, mostly as part of a more artist friendly GUI. I am more than
    willing to work on GUI refactoring, and I think I proceed with it as soon as time
    permits. Anyway, feel free to suggest/propose whatever you want to see in Freestyle.
    Thanks.



  17. #1017
    Originally Posted by T.K. View Post
    @mzungu
    Thank you for the comments. I fully agree that Freestyle needs an artist-frendly
    UI. I have been long considering how to put such a UI into the Freestyle framework.
    As a reference, I have in mind the UI of Pencil+, a NPR shader plug-in for 3ds Max:
    http://www.psoft.co.jp/en/product/pencil/
    Maybe something similar to this will meet a large portion of user requirements.

    What I really don't want to do is to weaken Freestyle's high programability.
    Freestyle is not only a bunch of predefined parameterized styles, but also
    intended to be a tool that allows you to define new styles based on novel
    stylization ideas and new parameters. A major requirement for a Freestyle UI
    is to keep this latter capability. This makes the design and implementation of
    the artist-friendly UI a non-trivial work. As discussed several times in the
    past, a node-based system would be an ideal UI that most people could imagine.
    IMHO, however, this approach is too ambitious if the present limited resources
    (i.e., time and developers) are taken into account.

    As an alternative idea, I have also been thinking of providing a versatile
    style module that comprises as many parameters as possible. This style module
    would not include any programability. Instead, it provides a fixed set of
    toggle buttons, sliders, menus for combining and manipulating style parameters.
    Let us consider including the following options:

    [feature edge selection: visible/invisible, nature (e.g., border, crease), 2D length, object names]
    [join rules: silhouette, same object ID, same nature]
    [stroke thickness: constant, variable, depth-dependent, depth discontinuity]
    [stroke color: constant, variable, material-based]
    [stroke modifiers: noise, tip removal, bezier curve fitting, backbone stretching]

    Combining these options will reproduce most of the standard style modules and
    give you more possibilities in a flexible manner. It is my impression that
    implementing this style module won't require too much.
    Sounds like a great proposal. I take it both the general GUI and style module would be written in Python and so would be easily customisable as well. I would also imagine that you would want a feature that could save and load presets that replicate the behaviour of some of the more common style modules. It would also be good if you could use the GUI to specify additional style modules to link in, as there would always be one parameter that you wanted to adjust that wasn't available in the general GUI.



  18. #1018
    Member
    Join Date
    Jan 2007
    Location
    Planet Earth
    Posts
    1,465
    Freestyle to trunk it approaching ? Node UI good for composition > Frestyle simple UI as noted it is generally acceptable.

    Advanced users can play with python and make some addons after.



  19. #1019
    Member
    Join Date
    Apr 2009
    Location
    New Zealand
    Posts
    228
    Have I found a bug? Can anyone else replicate this? Trying a simple material boundary render.

    I am using build 29070 minGW winXP

    I can do the trivial material boundary render ala

    Take the default cube, subdivide, assign one material to half the verts, and another to the rest. Select style qi0.py
    Render - no problems. Enable material boundaries, render - no problems.

    Replace default cube with suzanne. Assign one material to suz, another to just her nose. Turn off material boundaries, qi0.py, renders fine. Enable material boundaries, crashes every time. console message only gets as far as "Detecting silhouette edges", but no messages or errors beyond that.



  20. #1020
    Thanks Dazzle for the problem report. Yes it was a bug in the feature edge detection at material
    boundaries. I have just committed a fix in revision 29279. I would appreciate it if you could test
    the fix.



Page 51 of 149 FirstFirst ... 41495051525361101 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •