[Bf-python] Modifier as an Object sub module

Thu Jul 6 10:06:00 CEST 2006

oops... Pose is now a submodule, so that Leaves Groups (I added) and 
Modifier Ken and myself added...
Thinking about this
Blender.Group is probably ok since it needs New/Get/Unlink - like most 
other modules do, it kind of fits in.

Thats leaves
Blender.Modifier   to be moved to
Blender.Object.Modifier

The reason I didnt make it a submodule to begin with is that I wasn't 
sure how to go about it, still arnt.

Is anyone available to move Modifiers into an object submodule before 
release?
- Cam

Campbell Barton wrote:
> Im not so against this but it opens up a can of worms...
>
> IMHO
> Noise could also be a Mathutils submodule
>
> And Pose, Group, and Modifier should be Object submodules.
>
> Not sure weather spesific constructs for line/triangle's are that 
> important, why not just use a tuple of vectors for a line and a 3 for 
> a  triangle?
> is there much gain in having a spesific datatype? - Less type checking 
> I suppose..
>
>
>
>
>
> Gilbert, Joseph T. wrote:
>> Post-issue commentary....
>>
>> I have to agree with Campbell that Draw is for GUI and that mathutils
>> was written for the purpose of general math utilities for importers. I
>> can see that this method was written more for working with geometry
>> import however.
>>
>> It was my intention originally to add some math primitives such as
>> triangle, cube, etc. to allow for some geometric math as well. Because
>> none of this code was added to mathutils originally we ended up adding
>> theeth's line intersection code to Mathutils.
>> Since we now have a geometry module with a general purpose utility it in
>> I would feel more comfortable moving it as a submodule of mathutils as
>> Mathutils.Geometry.  We could then add some objects to represent Line,
>> Triangle, etc. and some math for boundary checks, and intersections,
>> etc. while the Geometry module (like mathutils) contains general
>> geometric utilities for importers/exporters.
>>
>> Joseph
>>
>> -----Original Message-----
>> From: bf-python-bounces at projects.blender.org
>> [mailto:bf-python-bounces at projects.blender.org] On Behalf Of Campbell
>> Barton
>> Sent: Sunday, July 02, 2006 2:00 AM
>> To: Blender Foundation Python list
>> Subject: Re: [Bf-python] Last minute addition
>>
>> All valid points, but your kind of missing some issues that casued me to
>>
>> add it.
>> 1) Mesh.fill() requires an object and mesh data, cycles editmode on 
>> and off and is also tagged experemental.
>> This means that for every fgon in an imported model it needs to go 
>> and create mesh data, a new object, add the verts then edges, fill in 
>> the data, get the faces indicies and return them. then clean up the 
>> mesh, object, restore  editmode data.
>>
>> 2) I have tested 500+ lightwave files out of 1700 that I have to import.
>>
>> many of these use a lot of fgons  so this function can be called a 
>> lot for each import. I have tested with .fill() and PolyFill() - 
>> polyfill is
>>
>> of course a lot faster, and dosent make the cursor flicker (seterate 
>> issue with cycline editmode a lot).
>>
>> Having good (fast+high quality) importers for blender is important, this
>>
>> fuction effects Lightwave and Obj.
>>
>> When testing fill() I kept on finding bugs and fill crashed blender - (3
>>
>> seperate bugs in fill()) - its good that blenders scanfill is now 
>> more stable, but directly  accessing the function is much neater.
>> In exasperation! - (trying to get these importers not to crash with 
>> blenders fill()), I asked Ton (who fixedall the bugs) if I could  
>> just access scanfill directly and add a hook in python. he seemd to 
>> think this would be okay, and gave me some help adding it in.
>>
>> The PolyFill Function its self isnt that complex, I have tested on 
>> importing meny models with no crashes.
>>
>> If you guys want Ill remove if but Im just putting forward a 
>> rationale for adding it in the first place, and that I added it when 
>> fixing bugs in Lightwave importer for release.
>>
>> Could we move it to BGL? Seems more closly linked to BGL then Draw.
>>
>> - Cam
>>
>>
>> Martin Poirier wrote:
>>  
>>> --- Martin Poirier <theeth at yahoo.com> wrote:
>>>
>>>      
>>>> --- Ken Hughes <khughes at pacific.edu> wrote:
>>>>
>>>>          
>>>>> If we need to "kick this idea around" then I have
>>>>>               
>>>> to
>>>>          
>>>>> ask, why is this being added during a CVS freeze?  It doesn't
>>>>>               
>>>> really
>>>>          
>>>>> fix a bug, and I don't think it's filling a hole in the API. I
>>>>> believe the commit said it was to avoid creating a mesh just to 
>>>>> fill it, but
>>>>> that just means this is redundant.  This is not coming from me as the
>>>>> "Mesh API father", it just seems rushed.
>>>>>               
>>>> I'll second that.
>>>>
>>>> Anything concerning the API has to be thought out,
>>>> because releases are "contracts" with *are* users
>>>>           
>>> that
>>>      
>>>> about the fonctionality and structure of the API.
>>>>           
>>> Obviously, that sentence should be read as: ...because
>>> releases are "contracts" with users, that *are* about
>>> the fonctionality and structure of the API.
>>>
>>> How that "are" moved two words to the left, nobody
>>> shall every know... :P
>>>
>>> Martin
>>>
>>> __________________________________________________
>>> Do You Yahoo!?
>>> Tired of spam?  Yahoo! Mail has the best spam protection around 
>>> http://mail.yahoo.com _______________________________________________
>>> Bf-python mailing list
>>> Bf-python at projects.blender.org
>>> http://projects.blender.org/mailman/listinfo/bf-python
>>>
>>>       
>>
>>
>>   
>
>

-- 
Campbell J Barton

133 Hope Street
Geelong West, Victoria 3218 Australia

URL:    http://www.metavr.com
e-mail: cbarton at metavr.com
phone: AU (03) 5229 0241