yang686526

incorrect vectorization of 2d solid
incorrect vectorization of 2d solid
hi,
we use the vectorization framework of dd libs 2.1.0 (vc8 and xcode builds) to import autocad formats into our app.
the attached drawing solid_color.dwg is rendered differently in our app from that in autocad, with the vectorization framework (refer acad2006render.png and ourapprender.png).
i was able to reproduce the problem with rendering in odamfcapp also on windows (refer odamfcrender.png). pdf export from odamfc is exhibiting the same behavior (refer odamfcsvgexport.pdf), but svg export from odamfc works fine (refer odamfcpdfexport.svg).
another query: we don't handle shellproc() explicitly, we just call odgigeometrysimplifier::shellproc() and rely on our primative line polygonout() etc being called. for the attached drawing, for each of the two solids in the file, we only get two calls to polygonout() with 3 points each (which form a triangular shape). how are we supposed to know that the color is to be applied as the fill of the figure and not the stroke?
putting it a little differently, how is the face of the solid supposed to be rendered correctly (completely filled with solid color in this case) when one is using odgigeometrysimplifier::shellproc()?
i had thought that vectorization would bring in a hatch or something to represent the face, but apparently that is not the case. any ideas?
attached files
looks as the same bug we experience in the posting
"selfintersecting solid failes default rendering implementation"
it should be fixed (or explained if it is an intended limitation).
-rune jorgensen

i think you are right, rune. this looks to be indeed the same problem. i didn't see any response from oda on your thread saying it was or would be fixed. have they communicated anything to you, off-the-forum?
also i would like to know from oda guys is how to go about the second problem: assuming even that the vectorization was correct, how do i know that the areas i am getting are to be filled in. my polygonout() only draws empty (unfilled) figures which have only stroke color set, since it is called both when the library intends to communicate a simple shape (like a rectangle) and when breaking down the entities as in from odgigeometrysimplifier::shellproc().
as i said before, i would have expected a hatch to be there to indicate that the area needs to be filled in with the set color, but i don't know how this fits into larger scheme of things.
regards,
varun
is there any solution?
vectorization issue was fixed in latest libraries.
thanks for fixing the issue.
but second problem mentioned by varun is not fixed.
is there any way to know which areas to be filled?
please reply to this thread, if you know any solution to this problem or want to
suggest anything.
thanks in advance.
hi,
you should check odgibasevectorizer::effectivetraits()::filltype() to determine if polygonout() should draw polygon filled or not (this does not take into account plot patterns).
code:
void mygeometry:olygonout(odint32 npts, const odgepoint3d* points, const odgevector3d*)
{
if (odgigeometrysimplifier::drawcontext()->effectivetraits().filltype()==kodgifillalways)
{
mydrawfilledpolygon(npts, points);
}
else
{
mydrawclosedpolyline(npts, points);
}
}
for more information please look into gs examples sources e.g.:
<dd folder>/extensions/exrender/win/exgsgdivectorizedevice.cpp:
void exgdivectorizeview:ntraitsmodified();
<dd folder>/extensions/exrender/win/exgigdigeometry.cpp:
void exgigdigeometry::draw_fillstyle(exgigdigeometry::f illstyle fillstyle);
void exgigdigeometry:olygonout(odint32 npts, const odgepoint3d* points, const odgevector3d*);
hi!
thanks for the suggestion.
i checked following condition in "ontraitsmodified" so that i can set fill attribute.
odgigeometrysimplifier::drawcontext()->effectivetraits().filltype()==kodgifillalways
this condition is returning true even for simple polyline object with no fill.
why it is returning true? is this a bug or am i not supposed to use this condition here?
i have seen two functions,
virtual const odgisubentitytraitsdata& odgibasevectorizer :: effectivetraits() const
and
odgigeometrysimplifier::drawcontext()->effectivetraits()
to get traits. what is the difference between these two functions?
when i should which function?
thanks in advance.
help!
please, look in to this issue!
thanks in advance.
ashwin
i also tried using effectivetraits().filltype() in my device's ontraitsmodified(), with little success.
all of the attached three files have figures which need to be unfilled. but for star.dxf and twolines.dxf, effectivetraits().filltype() returns kodgifillalways.
what am i doing wrong?
attached files (24.7 kb, 3 views)
(26.1 kb, 5 views)
(24.7 kb, 3 views)

regards,
varun
hi,
try to setvar "lwdisplay" = off and your star will be look with no width.
the lineweight of the lwpolyline is:
lineweight 211
the lineweight-property is another property and different to plinewid-property of a "polyline-object"!
with lwdisplay=on, the result of winopengl looks different to wingdi - special at polylineends. wingdi seems to be render a better result in this case.
summary:
lwdisplay -> display for lineweight
fillmode -> display for plinewid
__________
ralph
attached files (35.0 kb, 7 views)

last edited by hi-cads; 8th january 2007 at 10:25 amfff">.
thanks ralph. but the problem we face is slightly different.
we need the information when to fill the shape. lineweight mapping is already correct in our case. if you look at the files "ourapprender.png", "odamfcrender.png" and "acad2006render.png" in the zip file in the first post on this thread, you'll see the two problems we were facing. namely:
incorrect geometry
area coming as unfilled
with integration of dd 2.2.0 libs, the first problem was corrected, but the second still remains for which the dd guys suggested the solution of checking odgibasevectorizer::effectivetraits()::filltype(). when we tried that, it fixes the solid issue, but breaks simple cases (like star and twolines) where the figure is supposed to be unfilled, but due to this change, comes as filled (i've tried to illustrate the problem in "problemillustrated.png").
can someone from dd look into this, please.
attached images (82.9 kb, 8 views)

regards,
varun
to fill a lwpolyline
hi,
the process to fillin a lwpolyline in autocad is to create a hatch with a solid pattern. the boundary of the hatch is the lwpolyline before.
where is the filltype in autocad or objectarx for lwpolylines? in objectarx documentation: ... polylines and simple arcs cannot be filled ...
___________
ralph
attached files (154.9 kb, 3 views)

last edited by hi-cads; 9th january 2007 at 01:24 amfff">.
yes, i am aware of that ralph. however, when the 2d solid is broken down by the dd vectorizor, all we get are calls to our device's primitives to draw out the lines. in the implementation of these, we need to know whether to fill in the figures or just stroke out the edges. currently we only apply stroke.
one might imagine that the vectorizor could break the solid into polylines and a hatch (as i said in the last statement of my first post) but apparently they do not do it that way. they want us to use filltype(), which i regret to say is not working as detailed above.
regards,
varun
varun,
filltype() has sense only inside polygonout(), but polylineout() should always draw unfilled polyline.
thanks dmitry. putting the check only inside polygonout() took care of all the above mentioned cases.
do we have to adapt our code in a similar manner for other primitives, such as circulararcproc(), nurbsproc() etc. also, or does breaking up a solid only result in calls to polygonout()?
thanks again.
regards,
varun
all other primitives are being represented by polygonout() and polylineout() during processing by dd rendering framework (gi/gs classes).
you can override other geometry primitive functions to customize geometry processing.