| Re: [ice-dev] [eavp-dev] STL importer up and running |
RobertAlso, the FXGeometryAttachment should be giving all objects an FXColorDecorator. You can get the render element for your shape using getRender(yourShape) on the attachment and then doing .setProperty("red", x) on the returned IRenderElement to set your shape's red value. "green" and "blue" work similarly.Kasper,I think your idea of having a second copy of the triangles is the correct solution here. Suppose for example we want to display two different Shapes based on the same .stl file with both being separately editable. Rather than keeping one list of Triangles for each, we can read the data into an object, perhaps called a TriangleSource, and provide an ImportedShape class which has a reference to it. Then we can control an object's display geometry by overloading ImportedShape's getTriangles() method to get a copy of the triangles from the TriangleSource, transform them in some way (such as by scaling), and return the result without having made any destructive edits to the imported data.On Wed, Jul 20, 2016 at 4:39 PM, kaspergam <kaspergam@xxxxxxxxxxxxx> wrote:_______________________________________________The basic STL import functions have been implemented and are working in my eavp fork KasperGam/eavp with the branch kasper/stl and in ICE under Robert/GeometryRefactor in ICE. It allows for importing a file detailing multiple objects into a union, making it easier to work with. Unfortunately, the node decorators are not functional yet so everything has a default black texture. There are some issues still with how the geometry editor can handle varying sizes of files- for example an STL file, or any geometry file for the matter, might have objects specified with lengths less than one - which would render the imported geometry invisible in the editor, at least initially. One solution is to auto-zoom to an appropriate distance with the camera to a bound that exactly fits the largest coordinate of the imported geometry. However, that causes problems with zooming (we have a static zoom amount) and with the coordinate system axes, which do not scale appropriately when zoomed. The second option is to scale the object automatically, which with our current data model will corrupt the model and it will scale an exported file from that data as well. This is presumably not what the user wants. Robert- what would you recommend we do here? I currently have added a scale property to the Shape class which simply multiplies the coordinates by the scale to stretch the object, but unless we want to hold onto another copy of the triangles there is no way of not manipulating the triangle data.Here is a screenshot of an STL file I made, rendered in ICE using the new model. Note that the scale is set to 100.I will also attach the STL file itself, as I worked hard on it ;)
ice-dev mailing list
ice-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ice-dev
_______________________________________________
eavp-dev mailing list
eavp-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eavp-dev