高级会员
注册日期: 06-11
帖子: 14579
精华: 1
现金: 224494 标准币
资产: 234494 标准币
|
【转帖】problems exploding 3dsolids
problems exploding 3dsolids
problems exploding 3dsolids
hello,
if you try to use tehe function "convert acis" with the attaced drawing,
you get several assertions (from stnode.cpp line 57)
the same happens if i use this dwg with some testcode and
explodegeometry() with the oddb3dsolid entitys.
(toolkit dd2.02_7 in static version)
if i use the testcode with toolkit dll version i don't get any assertions.
so far the testcode. big problems in my hugeapp. (this is the one for the customers)
in this app if i try to use the toolkit in dll version, then odrxdynamiclinker()->loadapp("modelergeometry", false); throws an exception (file not found modelergeometry.drx)
i couldnt figure out where to put the dlls to make this going.
if i change the hugeapp to static link the toolkit, it initializes fine. but it does not return from the call to explodegeometry() with the first
oddb3dsolid. in this state it cpu is at 100% and even over night it does not finish. do you have any ideas what goes wrong ? is there a problem in the dwg?
if i try the explodegeometry wit my bigapplication it beh
attached files
no answer jet?
maybe i should clarify my questions:
- what must be done for explodegeometry to work properly?
- gives the assertion a hint to you that there is a problem with explodegeometry or the solid? or is there an initialisation problem in my app?
- can i specify the path where dd searches the dlls?
("odrxsetmodulesearchpath" does not work, it's unresolved)
- what else reason can it be if loadapp throws the "file not found" exception
can anyone see the problem in the code?
hello,
i still have the problems. attaced is a part of my application.
i had to remove some stuff which is irrelevant for opendwg concern.
im using dd2.2.0.0 / vc2003md
can anyone find the reason for explodegeometry() to fail?
taking the dwg from my first mail and iterating all the oddb3dsolid entities
in some cases explodegeometry() returns as expecxted
(result==eok, array filled),
in some other cases it retuns result==ecanotexplodegeometry,
and worse with the first oddb3dsolid in the example drawing it doesnot return at all.
is using explodegeometry() a recomended way to get simple visualisation data or is there some more recomended way to do this?
attached files (1.5 kb, 3 views)
i have put an answer in your personal message area on this forum
rgds
hi,
modelergeometry.drx should be in exe folder of your application.
asserts are inside out acis renderer module, it can be skipped.
i have tested your file with 2.2.0, i didn't find any problems with convertacis in mfcapp (debug\release vc2003 dll). also mfcapp didn't got infinite loop.
to dublin:
i answerd. it is nice to see that you can read the file.
but not my application.
to alexander rumyantsev:
that's my problem. with odamfcapp i donot have problems; only 4 asserts arise. but my application does not work properly.
i posted the opendwg relevant part of my code in my last post.
did anyone look at it?
any comments?
could there be a "out of memory" problem? (the complete app is huge)
dirk
hi,
i cannot help you, if i cannot reproduce bug here. was your application based on one of our sample ? for example, our odreadex can be changed to test explodegeometry functionality.
like ...
code:
class oddb3dsolid_dumper : public oddbentity_dumper
{
public:
void dump(std(_tostream) &os, oddbentity* pent, int indent) const
{
oddb3dsolidptr psolid = pent;
odrxobjectptrarray entityset;
writeline(os, indent, dd_t("start ..."));
odresult res = psolid->explodegeometry(entityset);
if (res != eok)
{
writeline(os, indent, dd_t("failedddddddddddddddddddddddddddddddddddddd ..."));
}
writeline(os, indent, dd_t("stop ..."));
}
btw : i think that problem can be in environment of your application. for example, your application and mfcapp use different ways of deviation calculation. so you can copy environment of readex to your application, if it works.
hi,
i'm sure now the problem must lie within our application.
but i do not understand what goes wrong.
i could narrow it down to the fact, that somehow the "drx" loading of the opendwg modules does not work, if i use opendwg within our application.
but i do not understand why.
after loadapp the result claimes to be ok. but if i call a function within the drx, the result is unpredictable. some calls work ok, some return erreos (you don't get in the examples) some calls don't return at all.
as we don't have te sources, i can't debug what happens.
i appended a screenshot of what i see when i break into the infinite loop.
i called "oddb3dsolid::explodegeometry" and i use dd2.02 msvc2003.
maybe you can give me a hint what goes wrong?
attached images (363.1 kb, 9 views)
odgetess is a tesselation algorithm. it was broken in 2.2.0. 3dsolid rendering uses odgetess for triangulation and it was broken too as result. infinite loop is one of broken tesselation effects.
we are about new release now, so fix will be available soon.
|