Another visualisation of selected faces:
[LDPartEditor] First Alpha Version News (until 2014-09-19)
Yes, I thought about it, but I am not going to change my project setup.
I will post detailed building instructions in the near future.
For now, I can only provide my ANT buildfile (for linux).
I will post detailed building instructions in the near future.
For now, I can only provide my ANT buildfile (for linux).
Code:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<project default="create_run_jar" name="Create Runnable Jar for Project LDPartEditor_linux">
<!--this file was created by Eclipse Runnable JAR Export Wizard-->
<!--ANT 1.7 is required -->
<target name="create_run_jar">
<jar destfile="/home/nils/workspace/LDPartEditor/LDPartEditor_linux_x86/LDPartEditor.jar" filesetmanifest="mergewithoutmain">
<manifest>
<attribute name="Main-Class" value="org.nschmidt.ldparteditor.main.LDPartEditor"/>
<!-- Modified Classpath -->
<attribute name="Class-Path" value=". plugin/"/>
</manifest>
<fileset dir="/home/nils/workspace/LDPartEditor_linux/bin"/>
<zipfileset excludes="META-INF/*.SF" src="/home/nils/workspace/LDPartEditor_linux/lib/lwjgl_util.jar"/>
<zipfileset excludes="META-INF/*.SF" src="/home/nils/workspace/LDPartEditor_linux/lib/lwjgl.jar"/>
<fileset dir="/home/nils/workspace/org.eclipse.swt_linux"/>
<zipfileset excludes="META-INF/*.SF" src="/home/nils/workspace/org.eclipse.swt_linux/swt.jar"/>
<fileset dir="/home/nils/workspace/org.eclipse.jface/bin"/>
<zipfileset excludes="META-INF/*.SF" src="/home/nils/workspace/jface/org.eclipse.core.commands_3.6.0.jar"/>
<zipfileset excludes="META-INF/*.SF" src="/home/nils/workspace/jface/org.eclipse.equinox.common_3.6.0.jar"/>
<zipfileset excludes="META-INF/*.SF" src="/home/nils/workspace/jface/org.eclipse.jface_3.5.0.jar"/>
<zipfileset excludes="META-INF/*.SF" src="/home/nils/workspace/jface/org.eclipse.osgi_3.6.0.jar"/>
<zipfileset excludes="META-INF/*.SF" src="/home/nils/workspace/jface/org.eclipse.ui.workbench_3.1.0.jar"/>
<fileset dir="/home/nils/workspace/com.sun.tools/bin"/>
<zipfileset excludes="META-INF/*.SF" src="/home/nils/workspace/runtime_compiler/tools.jar"/>
<zipfileset excludes="META-INF/*.SF" src="/home/nils/workspace/LDPartEditor_linux/swt-grouplayout.jar"/>
<zipfileset excludes="META-INF/*.SF" src="/home/nils/workspace/LDPartEditor_linux/swing2swt.jar"/>
<zipfileset excludes="META-INF/*.SF" src="/home/nils/eclipse/plugins/org.eclipse.core.databinding_1.4.1.v20130515-1857.jar"/>
<zipfileset excludes="META-INF/*.SF" src="/home/nils/eclipse/plugins/org.eclipse.core.databinding.beans_1.2.200.v20130515-1857.jar"/>
<zipfileset excludes="META-INF/*.SF" src="/home/nils/eclipse/plugins/org.eclipse.core.databinding.observable_1.4.1.v20130515-1857.jar"/>
<zipfileset excludes="META-INF/*.SF" src="/home/nils/eclipse/plugins/org.eclipse.core.databinding.property_1.4.200.v20130515-1857.jar"/>
<zipfileset excludes="META-INF/*.SF" src="/home/nils/eclipse/plugins/org.eclipse.jface.databinding_1.6.200.v20130515-1857.jar"/>
<zipfileset excludes="META-INF/*.SF" src="/home/nils/eclipse/plugins/com.ibm.icu_50.1.1.v201304230130.jar"/>
</jar>
</target>
</project>
LDPartEditor will also support CSG.
Here are screenshots from the first implementation draft:
A "union" with a cube and a sphere:
https://lh3.googleusercontent.com/-vo20S...csg_v2.png
A cube "minus" a sphere and its intersection with another sphere:
https://lh6.googleusercontent.com/-YZk9r...g_v2_2.png
RESULTS of the final implementation
Here are screenshots from the first implementation draft:
A "union" with a cube and a sphere:
https://lh3.googleusercontent.com/-vo20S...csg_v2.png
A cube "minus" a sphere and its intersection with another sphere:
https://lh6.googleusercontent.com/-YZk9r...g_v2_2.png
RESULTS of the final implementation
Code:
0 // CSG commands can be used in subfiles, too
0 // The identifiers are non-global and bound to the file / subfile
0 // It is possible to inline CSG commands from subfiles
0 BFC CERTIFY CCW
0 // SYNTAX 1 0 !LPE [CSG FORM] [ID] [COLOUR] [MATRIX]
0 !LPE CSG_CUBOID a 4 0 0 0 1 0 0 0 1 0 0 0 1
0 !LPE CSG_ELLIPSOID b 1 0 0 0 1.35 0 0 0 1.35 0 0 0 1.35
0 !LPE CSG_CYLINDER c 2 0 -1 0 .7 0 0 0 2 0 0 0 .7
0 !LPE CSG_CYLINDER d 2 -1 0 0 0 2 0 .7 0 0 0 0 .7
0 !LPE CSG_CYLINDER e 2 0 0 -1 .7 0 0 0 0 .7 0 2 0
0 // SYNTAX 2 0 !LPE [CSG FUNCTION] [ID] [ID2] [ID3]
0 !LPE CSG_UNION c d d
0 !LPE CSG_UNION d e d
0 !LPE CSG_INTERSECTION a b f
0 !LPE CSG_DIFFERENCE f d f
0 // SYNTAX 3 0 !LPE CSG_COMPILE [ID]
0 // The COMPILE command displays the CSG volume on the screen
0 // Inlining the following line will generate triangles of the CSG volume
0 !LPE CSG_COMPILE f
0 // E.g.
0 // Inlined: !LPE CSG_COMPILE f
3 4 -10 1.5752766 7.3133416 -10 1.5752766 8.313231 -10 3.3930404 7.6749177
3 4 -10 1.5752766 7.3133416 -10 -2.6084895 6.481139 -10 -2.6084895 7.9504156
3 4 -10 1.5752766 7.3133416 -10 -2.6084895 7.9504156 -10 9.094947E-16 8.866396
...
edit: Adjusted transformation matrix syntax to LDraw standard
edit2: changed !LD_PART_EDITOR meta command to !LPE
LDPartEditor's manipulator will support
- Local and global transformations, with a customisable pivot point ( [0;0;0] for global transformation )
- Translation
- Rotation
- Scaling
- A combined mode of Translation, Rotation, Scaling
- Transformation of adjacent data (disengageable)
- Subfile content modification (disengageable)
- Protection mechanisms for official library parts (e.g.: the accidental translation of three vertices from a primitive like 4-4disc.dat)
I implemented a bunch of new features for the 3D manipulator in this week and the week before.
You can now...
PS: I will change the icon design and the icon order from time to time to better clarify the unique features which are kept behind these buttons and improve the usablility. By now, it's a little bit cryptic
You can now...
- ...transform the camera to the position and orientation of the manipulator.
- ...swap and invert the manipulator axes.
- ...adjust the orientation of the manipulator to the nearest vertex, edge, or surface normal.
- ...adjust the position of the manipulator to the nearest vertex, edge, or surface.
- ...adjust the position of the manipulator to the selection center.
- ...adjust the position and orientation of the manipulator via the transformation matrix of a selected subfile.
PS: I will change the icon design and the icon order from time to time to better clarify the unique features which are kept behind these buttons and improve the usablility. By now, it's a little bit cryptic
LDPartEditor will support the full "Language Extension for Texture Mapping".
Here are the first screenshots showing "!TEXMAP PLANAR" doing its magic
..early version of the TEXMAP parser (you can see tiny white edges in the texture)..
..early version with transparency..
..now with improved image quality...
Here are the first screenshots showing "!TEXMAP PLANAR" doing its magic
..early version of the TEXMAP parser (you can see tiny white edges in the texture)..
..early version with transparency..
..now with improved image quality...
Code:
0 !TEXMAP START PLANAR 0 0 0 10 0 0 0 10 0 checker.png
0 !: 4 16 0 0 0 10 0 0 10 10 0 0 10 0
0 !TEXMAP FALLBACK
4 16 0 0 0 10 0 0 10 10 0 0 10 0
0 !TEXMAP END
0 !TEXMAP START CYLINDRICAL 15 10 0 15 0 0 15 10 -5 3.14 checker.png
0 !: 1 16 15 0 0 5 0 0 0 10 0 0 0 5 4-4cyli.dat
0 !TEXMAP FALLBACK
1 16 15 0 0 5 0 0 0 10 0 0 0 5 4-4cyli.dat
0 !TEXMAP END
0 !TEXMAP START SPHERICAL 25 5 0 25 5 -5 30 5 0 3.14 3.14 checker.png
0 !: 1 16 25 5 0 5 0 0 0 5 0 0 0 5 8-8sphe.dat
0 !TEXMAP FALLBACK
1 16 25 5 0 5 0 0 0 5 0 0 0 5 8-8sphe.dat
0 !TEXMAP END
I don't know if it is displayed correctly. I need more information for the SPHERICAL and CYLINDRICAL projection methods since they are difficult to understand. I simply don't know what I should expect when I do a "SPHERICAL" or "CYLINDRICAL" mapping with !TEXMAP...
https://lh3.googleusercontent.com/-_lcQ5...AP_ALL.png
For cylindrical, definitely if you have the settings right to match the cylinder that you're mapping onto, the checkerboard should indeed wrap around the cylinder and look even. For a unit half-cylinder centered with its bottom at 0, 0, 0, I believe the parameters would be 0 0 0 0 -1 0 0 0 1 180. (I color coded the numbers to make it easier to read.) With those settings, the left edge of the texture would map to left edge of the half-cylinder, the right edge of the texture would map to the right edge of the half-cylinder, and the middle bottom of the texture would be at coordinates 0, 0, 1, which would be the bottom center of the half-cylinder's surface.
For spherical, I'm not completely sure what it's supposed to look like, but if you used the same texture map for all three shapes, I don't think what you have is right. However, I believe for a unit sphere at the origin with texmap params 0 0 0 0 0 1 1 0 1 180 180, the center of the texture would map to the point at 0 0 1, and the texture near that point would look fairly non-warped. The checkerboard would get progressively more warped as you move further from that point. The centers of each of the four edges of the texture would map to the edge of the half-sphere, and everything outside a circle inscribed in the texture's square would be invisible (out of bounds).
For spherical, I'm not completely sure what it's supposed to look like, but if you used the same texture map for all three shapes, I don't think what you have is right. However, I believe for a unit sphere at the origin with texmap params 0 0 0 0 0 1 1 0 1 180 180, the center of the texture would map to the point at 0 0 1, and the texture near that point would look fairly non-warped. The checkerboard would get progressively more warped as you move further from that point. The centers of each of the four edges of the texture would map to the edge of the half-sphere, and everything outside a circle inscribed in the texture's square would be invisible (out of bounds).
Thanks Travis. I finally managed to find a solution for the cylindrical projection.
Code:
0 // btw: I changed the unit to degrees instead of radians
0 !TEXMAP START CYLINDRICAL 15 10 0 15 0 0 15 10 -5 180 checker.png
0 !: 1 16 15 0 0 5 0 0 0 10 0 0 0 5 4-4cyli.dat
0 !TEXMAP FALLBACK
1 16 15 0 0 5 0 0 0 10 0 0 0 5 4-4cyli.dat
0 !TEXMAP END
Very nice,
I would expect the spherical one to look like the right green/yellow one on this page
https://en.wikipedia.org/wiki/UV_mapping
I would expect the spherical one to look like the right green/yellow one on this page
https://en.wikipedia.org/wiki/UV_mapping
Two things. First, it appears that the spec doesn't specify the units for the angle. However, since it is designed to be easy to use for part authors, I feel that it should be degrees.
Secondly, Phil's suggestion of what the sphere should look like may be correct, but I'm not sure. I'm not having any luck wrapping my head around the description for the spherical projection.
Secondly, Phil's suggestion of what the sphere should look like may be correct, but I'm not sure. I'm not having any luck wrapping my head around the description for the spherical projection.
'Little thing'
For the outer top and bottom ones all horizontal angles are correct, so the only way to get a perfect textured sphere you have to take into account the other points of the triangle/quad you're working on (creating multiple vertices for the same top/bottom xyz).
The same problem with -180/180 coordinates. Don't you have this problem at the backside of the sphere/cylinder?
On the other hand I'm wondering if the spec was ment to be used on enclosed objects, it being projection orientated and all.
I'm also curious... how does it look when you map a texture on something when the outer edges of the texture don't align with ldraw points? e.g. a -60..60 deg on a 16 facet cylinder (texture should starts and end in the ~middle of a segment?)
For the outer top and bottom ones all horizontal angles are correct, so the only way to get a perfect textured sphere you have to take into account the other points of the triangle/quad you're working on (creating multiple vertices for the same top/bottom xyz).
The same problem with -180/180 coordinates. Don't you have this problem at the backside of the sphere/cylinder?
On the other hand I'm wondering if the spec was ment to be used on enclosed objects, it being projection orientated and all.
I'm also curious... how does it look when you map a texture on something when the outer edges of the texture don't align with ldraw points? e.g. a -60..60 deg on a 16 facet cylinder (texture should starts and end in the ~middle of a segment?)
Roland Melkert Wrote:On the other hand I'm wondering if the spec was ment to be used on enclosed objects, it being projection orientated and all.
One of the few places off the top of my head that I can see a use for spherical mapping would be to put texture onto a LEGO ball (like the Hero Factory mixed color shooter balls).
Roland Melkert Wrote:I'm also curious... how does it look when you map a texture on something when the outer edges of the texture don't align with ldraw points? e.g. a -60..60 deg on a 16 facet cylinder (texture should starts and end in the ~middle of a segment?)
The angle that the part author puts into the file is expected to match the angle covered by the textured geometry, so your question seems moot. Remember, textures are always applied to whole facets in the LDraw !TEXMAP extension. It's up to the author to specify correct !TEXMAP parameters for the geometry the texture is being applied to.
Travis Cobbs Wrote:One of the few places off the top of my head that I can see a use for spherical mapping would be to put texture onto a LEGO ball (like the Hero Factory mixed color shooter balls).
Maybe use two texture commands (on two half sphere's) for that (project one on to the top and one on to the bottom) to avoid the whole multiple correct uv coordinates for an LDraw point problem.
Travis Cobbs Wrote:The angle that the part author puts into the file is expected to match the angle covered by the textured geometry, so your question seems moot.
so it's up to the authors to pad the texture sources, I can live with that
I took some backup from my university to solve this problem (a physicist and a professor in mathematics). It turns out, that imperfect polar caps are the effect of the mathematical definition of the perfect sphere and the limited resolution of our LDraw spheres. Ray tracers do not have this problem. The image on the wikipedia article, which was mentioned by Roland, was generated by a raytracer. An alternative solution would be to cut off the polar caps and use a planar projection only on the (nearly planar) polar caps.
The problem is not solvable mathematically under this circumstances and I do not intend to find a workaround which might expand the current TEXMAP spec.
This night, I will upload a video and more screenshots with different angle configurations to better visualise the capabilities of the TEXMAP meta command.
The problem is not solvable mathematically under this circumstances and I do not intend to find a workaround which might expand the current TEXMAP spec.
This night, I will upload a video and more screenshots with different angle configurations to better visualise the capabilities of the TEXMAP meta command.
Is there a set of (unofficial) parts to use for testing? Preferable ones using all three kinds of mapping and some sort of nesting etc in order to test all texture usages in one go.
This thread made me want to give it a go to in LDCad too , most work will go into setting up the support stuff though (and keeping normal rendering fast), but I'm hoping to get something going this weekend.
This thread made me want to give it a go to in LDCad too , most work will go into setting up the support stuff though (and keeping normal rendering fast), but I'm hoping to get something going this weekend.
I only made planar projection parts, since this is the only projection supported by LDView (and the most useful I think, since to acquire images of real parts, you generally use a photo... planar!).
For examples, see http://forums.ldraw.org/showthread.php?t...58#pid9858 and http://forums.ldraw.org/showthread.php?t...21#pid7921
For examples, see http://forums.ldraw.org/showthread.php?t...58#pid9858 and http://forums.ldraw.org/showthread.php?t...21#pid7921
Thanks,
As for the types: for normal up front pictures planar would be fine indeed, cause the source picture automatically includes the projection stretch needed.
But when working with (official) Lego stickers you probably need to use the cylinder and or sphere to account for projection stretching/shrinking when the target area is (very) curved.
As for the types: for normal up front pictures planar would be fine indeed, cause the source picture automatically includes the projection stretch needed.
But when working with (official) Lego stickers you probably need to use the cylinder and or sphere to account for projection stretching/shrinking when the target area is (very) curved.
Thanks! The attached pictures are the checker-board texture UV-mapped to a sphere using typical sphere-mapping from a 3-d modeler.
The left sphere is made from a small number of segments, the right a much larger number. Since the UV map is per vertex you can see the 'sphere' lines aren't well-projected on the left.
The 3-d modeler can get the caps right because for each vertex it knows the connectivity to neighboring vertices; a straight vertex->uv function is going to introduce discontinuities or wrap-around and possibly undefined results at the poles.
So theoretically if you have your triangles in advance and you are applying a mapping function to each one to pre-compute UV, you could 'solve' the poles with some analysis. I don't think you can do this in shader without geometry shaders and a ton of work.
I'm not a fan of using projection for part textures at all - the rest of the modeling world uses UV mapping, which makes the projection of parts, management of discontinuities, and other complex issues not the problem of the file format and every client that reads it.
The left sphere is made from a small number of segments, the right a much larger number. Since the UV map is per vertex you can see the 'sphere' lines aren't well-projected on the left.
The 3-d modeler can get the caps right because for each vertex it knows the connectivity to neighboring vertices; a straight vertex->uv function is going to introduce discontinuities or wrap-around and possibly undefined results at the poles.
So theoretically if you have your triangles in advance and you are applying a mapping function to each one to pre-compute UV, you could 'solve' the poles with some analysis. I don't think you can do this in shader without geometry shaders and a ton of work.
I'm not a fan of using projection for part textures at all - the rest of the modeling world uses UV mapping, which makes the projection of parts, management of discontinuities, and other complex issues not the problem of the file format and every client that reads it.
I found a "solution" here, but this would extend the current TEXMAP specification and assumes that every geometry placed around the polar caps is a triangle.
On the one hand, there is loss of texture information near the caps, since you can't project every point from the 2D image on the sphere.
On the other hand, it is impossible to find a solution for surfaces which are streched across the caps.
How do we proceed now?
On the one hand, there is loss of texture information near the caps, since you can't project every point from the 2D image on the sphere.
On the other hand, it is impossible to find a solution for surfaces which are streched across the caps.
How do we proceed now?
Ben Supnik Wrote:I'm not a fan of using projection for part textures at all - the rest of the modeling world uses UV mapping, which makes the projection of parts, management of discontinuities, and other complex issues not the problem of the file format and every client that reads it.
The spec was adapted on a 'as is' basis, mainly because it's (authoring) user friendless and the wishes of the spec author(s). I was not too happy with this but I believe most were happy with it. It's a bit disappointing there no real parts (except the one helmet) made to really test the spec yet though.
On the other hand we probably could extend the extension by adding a special meta line supplying hard coded uv cords for the next type 3 or 4 line in a file, e.g.
!TEXMAP UV NEXT 0.0 0.0 1.0 0.0 1.0 1.0 0.0 1.0
0 !: 4 16 ..........
to solve the really complicated authoring needs, but then again I'm not completely sure it was supposed to be used on enclosed objects anyway.
I am very busy right now.
Here is a new video on youtube which says more than 1000 words.
https://www.youtube.com/watch?v=S_6hx10kwZU
Here is a new video on youtube which says more than 1000 words.
https://www.youtube.com/watch?v=S_6hx10kwZU
Would it be possible to get the colours sorted in actual colour order, and not after colourname (alfabetical) or colournumber (numerical) ?
Or in a layout, like a colourwheel, but with only the defined ldraw colours choosable?
Or grouped after their properties: base, brighter shades, darker shades, transparent, chromed, speckled, rubber, common?
Some sort of colour coordinated ldconfig layout.
I would like to be able to compare all the different shades of e.g. yellow.
Or in a layout, like a colourwheel, but with only the defined ldraw colours choosable?
Or grouped after their properties: base, brighter shades, darker shades, transparent, chromed, speckled, rubber, common?
Some sort of colour coordinated ldconfig layout.
I would like to be able to compare all the different shades of e.g. yellow.
https://lh5.googleusercontent.com/-oAcYP...Edger2.png
You can set the scope to the following levels:
Default values:
af = 0.1°
ac = 60°
ae = 60°
The -cx and -cv options are not supported since LDPartEditor has other mechanisms to detect and remove invisible condlines.
You can set the scope to the following levels:
- File, Subfiles and primitives
- File only
- Current Selection
Default values:
af = 0.1°
ac = 60°
ae = 60°
The -cx and -cv options are not supported since LDPartEditor has other mechanisms to detect and remove invisible condlines.
It is now possible to define background images.
BG images can be created for custom viewing angles and positions.
A BG image is invisible if the viewing angle from the viewport does not match the viewing angle of the image.
You can scale the image on the x and y axis, too.
https://lh3.googleusercontent.com/-_zNOY...images.png
BG images can be created for custom viewing angles and positions.
A BG image is invisible if the viewing angle from the viewport does not match the viewing angle of the image.
You can scale the image on the x and y axis, too.
Code:
0 // SYNTAX:
0 // 0 !LPE PNG [color=#FF0000][pos X] [pos Y] [pos Z][/color] [color=#00CCDD][X axis rotation angle in degree] [Y axis rot.] [Z axis rot.][/color] [color=#FF9933][scale X] [scale Y][/color] [path]
0 !LPE PNG [color=#FF0000]0 0 10[/color] [color=#00CCDD]90 0 0[/color] [color=#FF9933]1 1[/color] \..\image.png
https://lh3.googleusercontent.com/-_zNOY...images.png
« Next Oldest | Next Newest »
Users browsing this thread: 2 Guest(s)