yang686526

ellipses and insert scales
ellipses and insert scales
hallo
how does one take into consideration negative scale factors on block inserts, especially regarding major and minor axis of ellipses? at the moment, i swap the major and minor radii, when a block insert has a negative scale in x or y, but the results i get are not always consistent. what i am doing wrong? i do take nested blocks into account.
thanks
anton heymann
for nested block references you can have a stack of transformations.
entering processing of block reference you multiply current transformation matrix by the oddbblockreference::blocktransform() matrix and push it into the stack.
odgeelliparc3d::transformby() will do the job applying the current matrix to the geometry.
sergey slezkin
ellipse normal
sergey
that is what i am doing at the moment, but some ellipses in my test suite of drawings are still inserted incorrectly into our application. what should be done in terms of the ellipse normal itself. when i insert an arc, when the normal is not equal to the zaxis, i swap the direction of the arc - this appears to be correct. in the case of an ellipse i also swap the direction, but the radii of the ellipses are still incorrect. i tried swapping them as well, but still no luck - any other suggestions.
thanks for advice so far!
anton heymann
further on from ellipse normal
sergey
if i use transformby (providing the current transformation matrix), does that then mean that i can disregard any special checking re the ellipse normal - for that matter, if that is the case, can i then also ignore all other entities while using transformby in terms of their normals e.g. polylines, arcs etc.?
regards
anton
you need not take special care about negative scales. simply call transformby(). but note that it may reverse normal of ellipse.
what kind of problem do you have?
btw, are you applying transformby() to odgeelliparc3d or oddbellipse?
sergey slezkin
transformby
sergey
i have always had problems correctly determining the start and end angles of arcs and ellipses, especially when the normal != kzaxis. in addition to problems with angles, i have now also encountered a problem with the radii of ellipses, which appear to be 'swapped' e.g. an ellipse that i draw starts at the wrong major radius and ends at the wrong minor radius. this is more apparent when the ellipse is within nested block inserts. at the moment i simply use transformby (using a stack) on the entity i find in the drawing e.g. oddbellipse and oddbarc - i do not use any other structure e.g. odgeelliparc3d.
anton
i assume that you call transformby() for a copy of oddb entity or use gettransformedcopy(). an entity inside a block can be rendered multiple times because the block containing it can be inserted multiple times with different transforms. the database resident entity must not be modified during processing.
applying current transform to an ellipse or arc does not project it on xy plane. and even in 2d drawing you may get entities with normal not equal to z axis. for example (0, 0, -1).
ellipse angles are measured from major axis around normal. so they need be processed differently for ellipse with (0, 0, 1) and (0, 0, -1) normals.
btw, if you need simply import geometry representation into your application probably it makes sense to look at odvectorize sample or our exports (dwf, svg, pdf). they use rendering framework to get the geometry.
sergey slezkin
ellipses
sergey
thanks for the information. i cannot use vectorisation in this instance as i am importing the information into a cad application, keeping the entity structure (blocks, layers etc.) as close to the original as possible.
referring to the information you have provided, should i use odgecircarc3d (for transformed arcs) and odgeelliparc3d (for ellipses). will this correctly transform the entity (a copy of it as per your advice) giving me the correct start, end angles and radii, provided i apply the block transform information. should i do any further calculations, taking the normals into account?
thanks
anton
anton,
i do not understand your task. what is the purpose of applying block reference transform to entities inside the block if your application supports blocks and block references?
let's try to start from the very beginning. what are you doing and which problems with negative scales do you have?
sergey slezkin
blocks
sergey
i have been using various instances of the oda libraries for many years and started using the libaries when they were first developed. obviously i have had many 'versions' of my application, supporting the various capabilities that the libraries provide(d). i am now in a position where i have 'bits' of old code (where i did by own version of block transformations), but obviously the libraries as it stand offers many new ways of determining the correct position of entities. so, i need to 'back engineer' a lot of my code and start incorporating newer capabilities and i have had a particular problem with ellipses (correctly inserted in terms of scale and rotation etc.) but with a small problem regarding inverted radii - which is where the whole conversation started. basically my code at the moment, incorporates some references to using transformby (using a transformation matrix stack) and other parts still have 'old' e.g. my own home brewed version of transformations.
what i am going to do now, is to redevelop some of my core code, making use of the advice that you have already provided, and once that is complete and i still have issues, i will ask for advice again.
thanks
anton
problem drawing
sergey
i have not looked at my application again, and i am still experiencing problems with arcs/ellipses.
in essence i am doing the following. when a block insert is entered, i get the 'current transformation' and save it on a stack :
curtransformation = _insert->blocktransform();
curtransformation *= odgematrix3d::translation(odgepoint3d::korigin - basept);
transformation *= curtransformation;
insstk[stkndx]->transformation = transformation;
when i then get to an entity i use the following code (as an example) :
oddbarcptr arc = oddbarc::cast(pent);
if (arc->gettransformedcopy(transformation,enttransforme d) == eok && !enttransformed.isnull())
{
arc = oddbarc::cast(enttransformed);
if (!arc.isnull())
{
arc->getstartpoint(startpoint);
arc->getendpoint(endpoint);
arc->getstartparam(sa);
arc->getendparam (ea);
arc->getpointatparam((sa + ea) * div2,midpoint);
odgeelliparc3d ellipse(odgecircarc3d(startpoint,midpoint,endpoint ));
ellipticalarc(ellipse);
}
}
essentially this code makes a copy of the transformed entity, creates an elliptical arc and then calls a function elliptical arc in our application to draw the arc. i also check if the ellipse's normal is equal to 0,0,-1 and if so reverse the direction of the ellipse.
i attach 4 screen shots of issues and a sample drawing (all in a zip file). files starting with oda... is a sample drawing as viewed via odamfcapp (correct) and our application (cad...) which is incorrect.
there must still be something that i am not correctly applying .
thanks
anton
attached files (271.8 kb, 3 views)

not - should read now
i have now looked at the application - soz.
your pictures show problems with elliptical arcs, and the code you provided can process only circular arcs.
btw, even oddbarc::gettransformedcopy() may return oddbellipse in case of non-uniscale transformation.
based on screen shorts it seems that you process start/end of arcs incorrectly mixing angle and parameter.
in oddbellipse class startangle() and getstartparam() are not the same. in odgeelliparc3d startang() actually returns parameter value (see description at the top of geelliparc3d.h)
sergey slezkin
success!
sergey
i have now progressed my import routine and i am able to load these types of entities with much greater consistency and accuracy. the 'clue' was the fact that gettransformedcopy can return a different entity type than the original - using that fact certainly made a huge difference. i am now importing my test suite of drawings correctly!
thanks
anton