commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wes Gilster <wesgils...@gmail.com>
Subject Re: Applicability of PolyhedronsSet for high polygon counts
Date Thu, 10 Nov 2016 18:47:18 GMT
Since you asked, I will bore everyone. :) I already know I'm not 
comparing apples to apples and this is extremely high level, but here 
are some performance numbers given an identical 3d STL model:

https://github.com/area515/Photonic3D/issues/283

If you want to get my initial opinion, it's going to be difficult to 
reach JMonkey's performance numbers and the efficiency for which they 
store their data structures(simple nio buffers).

The bad news for JMonkey is that I don't see how their JBullet physics 
engine is going to provide the specific geometry I'm looking for. I 
haven't dug into their API yet, but it feels like I'll need to interpret 
collision vectors rather than having an intersection mesh and I'm really 
not sure where that would take me. I haven't been able to easily 
reproduce the intersection geometry that the Apache PolyhedronsSet seems 
to give.

Analysis has basically just begun. Next I need to look more at the API 
for JMonkey's implementation of the JBullet Physics engine.


Thanks,

Wes G.

On 11/9/2016 12:06 PM, Gilles wrote:
> Hi.
>
> Please keep us informed of your findings...
>
> Best regards,
> Gilles
>
> On Sat, 5 Nov 2016 22:40:10 -0500, Wes Gilster wrote:
>> I really appreciate the quick response. Even though I believe this
>> API has the functionality I need, I'm not really sure I can easily
>> tune the performance. I need to check out a few other APIs to
>> determine if they will be a better fit, and if I can't find anything
>> that fits, I'll probably see what I can do with this geom package.
>> Thanks again for being so upfront about the state of the project.
>>
>> Thanks,
>>
>> Wes G.
>>
>> On 11/5/2016 11:03 AM, Gilles wrote:
>>> Hello.
>>>
>>> On Fri, 4 Nov 2016 23:57:48 -0500, Wes Gilster wrote:
>>>> I've been using the commons math geometry libraries for some simple
>>>> 2d intersection functions, but I'm now interested in expanding it's
>>>> use to include some manipulation of 3d models with polygon counts that
>>>> will easily reach 200,000 tris. More specifically I would like to
>>>> build physical support structures in 3d models. Given that commons
>>>> math geo libraries used BSP trees, I had assumed the performance would
>>>> be quite adequate. However I'm having second thoughts as to whether
>>>> this is the right API for this modeling. I'm building models from STL
>>>> files with this constructor:
>>>>
>>>>
>>>> org.apache.commons.math3.geometry.euclidean.threed.PolyhedronsSet.PolyhedronsSet(List<Vector3D>,

>>>>
>>>>
>>>> List<int[]>, double)
>>>>
>>>> It seems there are some quite in-efficient loops in here, and with
>>>> models with high polygon counts this function really performs poorly:
>>>>
>>>>
>>>> org.apache.commons.math3.geometry.euclidean.threed.PolyhedronsSet.buildBoundary(List<Vector3D>,

>>>>
>>>>
>>>> List<int[]>, double)
>>>>
>>>> It also seems as though this API is going to be quite intolerant of
>>>> imperfect geometry.
>>>>
>>>> Below is an example that loads an STL from disk and inserts into this
>>>> the PolyhedronsSet:
>>>>
>>>>
>>>> https://github.com/WesGilster/Photonic3D/blob/master/host/src/main/java/org/area515/resinprinter/supports/ImpossiblePerformance.java

>>>>
>>>>
>>>>
>>>> I'm hoping someone with a bit of experience in this API could confirm
>>>> this assessment.
>>>
>>> I have no good news; there is probably no one listening here who
>>> has more experience than you on using this part of the Commons
>>> Math library.
>>>
>>> Many of the more advanced codes (in size and/or complexity) have
>>> been orphaned by a fork last May.
>>>
>>> A lot of discussion has arisen about the future of CM (have a look
>>> at the ML archive if you are interested).
>>> Some parts have found new maintainers.
>>> We should certainly welcome people who have expertise with using the
>>> "geometry" package, to improve and maintain it, and eventually
>>> release it as a standalone component.
>>>
>>>
>>> Best regards,
>>> Gilles
>>>
>>>>
>>>> Thanks,
>>>> Wes G.
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message