> (in python, yade.utils.{sphere,facet,wall} assigns AABB, and there
> is no way to assign no BoundingVolume in python at all... we will figure
> that out somehow, though)
I stand corrected. You _can_ assign None to Body().bound in python,
which will reset the pointer to shared_ptr() internally.
G
> Hm... I used this approach with previous desing: I don't assing
> InteractingGeometry with virtual facets (utils.facet have a
> noInteractingGeometry flag so far). But, seems, the collider would to
> give a errors if body have not a bounding volume... or not?
InsertionSortCollider handles that b
> I'd be a little careful with adding duplicate virtual classes,
> though. A flag in the InteractingGeometry might do as well.
>
Yes, this design seems more appropriate than adding parallel class
hierarchy... Occam's razor principle...
> Oh, BTW, if your body doesn't have bounding box, it will no
> Thanks! I will do likewise.
> And if we don't have GeometryModel any more, may be do rename
> InteractingFacet to Facet? So, we will have, for example,
> Facet for the interacting facets and VirtualFacet for noninteracting facets.
Pssst for renaming... Of course in due time, Interacting* will be
Bruno Chareyre:
>
>>> But, what if body have a geometry model but not a interacting>
>>> geometry? (i.e. body don't interact with other bodies). So, that body
>>> is> "virtual" body. I need this type of bodies in order to generate
>>> new> spheres on their surface/volume in course of sumulation.
>
> But, what if body have a geometry model but not a interacting
> geometry? (i.e. body don't interact with other bodies). So, that body is
> "virtual" body. I need this type of bodies in order to generate new
> spheres on their surface/volume in course of sumulation.
Alternately to Bruno's sugges
But, what if body have a geometry model but not a interacting
geometry? (i.e. body don't interact with other bodies). So, that body is
"virtual" body. I need this type of bodies in order to generate new
spheres on their surface/volume in course of sumulation.
I know what you mean...
1. You
Václav Šmilauer пишет:
> As suggested earlier on the list, I will be deprecating
> GeometricalModel. Files that need it for functionality will be marked
> YADE_REQUIRE_FEATURE(shape), hence unfunctional in regular builds.
> Later, they will be removed.
>
But, what if body have a geometry model bu
Václav Šmilauer said: (by the date of Wed, 18 Nov 2009 13:59:18 +0100)
> Since there was surprisingly no reaction,
I have seen that, but I suffer a time-o-disease. When you go forward
with developing so fast (I do sometimes) others have plain difficulty
to catch up.
This annoyed me as hell i
>
> Concerning the fix in Triaxial files, when I have this :
>
> #ifdef YADE_SHAPE
> shared_ptr gSphere(new Sphere);
> gSphere->radius= radius;
> gSphere->diffuseColor= spheresColor;
> gSphere->wire= false;
> gSphere->shad
Many *Triaxial* classes are also disabled; the createSphere function is
copied about 7 times in the source and I fixed only a few of them, which
is a trivial fix.
Concerning the fix in Triaxial files, when I have this :
#ifdef YADE_SHAPE
shared_ptr gSphere(new Sphere);
gSph
Since there was surprisingly no reaction, here is a list of files that
won't compile with the current revision, since they rely on
GeometricalModel (or rely on files which rely on GeometricalModel etc).
Some of them are GeometricalModel's themselves, which will be removed,
but you should fix the o
Hi everybody,
as announced, r1789 (symbolic number: prise de la Bastille) removes
GeometricalModel. I fixed some code by hand, but many classes are not
being compiled now. I added new feature 'shape' that compiles everything
as it used to be.
Classes that are not compiled are marked by YADE_REQUI
As suggested earlier on the list, I will be deprecating
GeometricalModel. Files that need it for functionality will be marked
YADE_REQUIRE_FEATURE(shape), hence unfunctional in regular builds.
Later, they will be removed.
Please adjust your code that relies on GeometricalModel to get the data
it n
Hi,
I would like to ask what is your opinion on the usefulness of
GeometricalModel, as opposed to InteractingGeometry.
It seems that the original ide (Janek?) was that InteractingGeometry
will be always derived automatically from GeometricalModel (as there is
InteractingGeometryMetaEngine that wo
15 matches
Mail list logo
