3D Part Preview added to Parts Tracker

[Orion Pobursky]

Hi Orion,

Which part of the code is it that is causing issues?

There are currently two ways of enabling and disabling logos:

LDR.Studs.makeGenerators() which can be called before the model is loaded to ensure that studs will be constructed correctly. I do not think this is the best option for setting the values here.

and

LDR.Studs.setStuds() which can be called to overwrite the part types for studs. After it has been called, the other parts that use studs will have to be rebuilt. To rebuild, the function removeAllMeshes() on meshCollectors can be used before calling draw() to rebuild.

I am having trouble. I'm using the LDR.Studs.setStuds() method.

Right now I'm doing something like this:

Code:

LDR.Studs.setStuds(ldrLoader, ldrOptions.studHighContrast, ldrOptions.studLogo, () => ldrLoader.load(partID));
ldrLoader.partTypes = {}; // Reset all stored data in the loader.
ldrLoader.load(partID);

This doesn't seem to work no matter what value I set ldrOptions.studLogo to.

[Lasse Deleuran]

I am having trouble. I'm using the LDR.Studs.setStuds() method.

Right now I'm doing something like this:

Code:

LDR.Studs.setStuds(ldrLoader, ldrOptions.studHighContrast, ldrOptions.studLogo, () => ldrLoader.load(partID));
ldrLoader.partTypes = {}; // Reset all stored data in the loader.
ldrLoader.load(partID);

This doesn't seem to work no matter what value I set ldrOptions.studLogo to.

The trick is to not clear the loaded data:

LDR.Studs.setStuds(ldrLoader, ldrOptions.studHighContrast = 0, ldrOptions.studLogo = 1, () => ldrLoader.load(partID));

sets the logo on studs.

LDR.Studs.setStuds(ldrLoader, ldrOptions.studHighContrast = 0, ldrOptions.studLogo = 0, () => ldrLoader.load(partID));

Clears the logo.

As an example, try to fire these commands in the console here: https://www.ldraw.org/parts/official-par...artid=3024

[Orion Pobursky]

The trick is to not clear the loaded data:

LDR.Studs.setStuds(ldrLoader, ldrOptions.studHighContrast = 0, ldrOptions.studLogo = 1, () => ldrLoader.load(partID));

sets the logo on studs.

LDR.Studs.setStuds(ldrLoader, ldrOptions.studHighContrast = 0, ldrOptions.studLogo = 0, () => ldrLoader.load(partID));

Clears the logo.

As an example, try to fire these commands in the console here: https://www.ldraw.org/parts/official-par...artid=3024

Works for the official library (with some camera shenanigans) but not the PT even though it's literally the same code. Weird. I guess I'll have to troubleshoot more.

[Lasse Deleuran]

Works for the official library (with some camera shenanigans) but not the PT even though it's literally the same code. Weird. I guess I'll have to troubleshoot more.

Hi Orion. Did you already fix this?

When I fire the command on https://www.ldraw.org/cgi-bin/ptdetail.c...60583b.dat, it works.

[Orion Pobursky]

Hi Orion. Did you already fix this?

When I fire the command on https://www.ldraw.org/cgi-bin/ptdetail.c...60583b.dat, it works.

Not working for regular studs (yet):
https://www.ldraw.org/cgi-bin/ptdetail.c.../30303.dat

I'm currently refactoring all the code so any fix will be incorporated into that.

[Lasse Deleuran]

In the latest push to master, I have added support for texmap. By default textures are found in the folder "textures". 

For other placements, the options parameter "idToTextureUrl" can be set. This is a function that takes a texture name and returns the location of the texture file.

Please see the following examples:

sample_texmap_opaque.htm

sample_texmap_trans.htm

sample_texmap_inline.htm

The only existing limitation is the physical render where I am limited to how textures are mapped onto standard materials. This causes the textures to 'wrap to edges', rather than just cutting off:

[Orion Pobursky]

In the latest push to master, I have added support for texmap. By default textures are found in the folder "textures". 

For other placements, the options parameter "idToTextureUrl" can be set. This is a function that takes a texture name and returns the location of the texture file.

You didn’t need to create a new function. The texture path should always be <part path>/texture/<texture name>

[Lasse Deleuran]

You didn’t need to create a new function. The texture path should always be <part path>/texture/<texture name>

I thought so as well, but I have had some issues with upper and lower case file names on one of my test sites. Now everyone has a handle to handle this issue, should it arise.

[Lasse Deleuran]

I have misunderstood the purpose of "0 BFC CLIP" and "0 BFC NOCLIP", leading to incorrect behaviour when the parser encountered these statements. The updated code base has this fixed.


This was discovered while working on the implementation of the converter from Studio 2.0 textures to the LDraw Texmap standard.

[Lasse Deleuran]

Another addition that would be useful (no idea of complexity involved!): possibility to display an origin/axis thingy to allow quick check of part origin and orientation...

I wanted to relax with an easier change yesterday, so I found this suggestion and implemented it. Please see sample_part.htm for how to enable an axes helper.

Other helper functions include viewing computed normals and seeing if the computed UV mapping is correct.

The vertex-normal, and thus UV calculation is done using a heuristic based on the presence of line type 2 and 5 starting from or ending at the vertices. Some part, such as 85080.dat have some funky usage of overlapping line type 5's causing the heuristic to fail. I am not sure if the heuristic should be even more complex, or if 85080.dat should be cleaned up.

[Philippe Hurbain]

I wanted to relax with an easier change yesterday, so I found this suggestion and implemented it. Please see sample_part.htm for how to enable an axes helper.

Looks interesting, but is there a way to see it working?

The vertex-normal, and thus UV calculation is done using a heuristic based on the presence of line type 2 and 5 starting from or ending at the vertices. Some part, such as 85080.dat have some funky usage of overlapping line type 5's causing the heuristic to fail. I am not sure if the heuristic should be even more complex, or if 85080.dat should be cleaned up.

I'm afraid the heuristics should be more complex, I see no problem in 85080. The overlapping condlines occur because the condlines included in cylinder prims are calculated to be OK with cylinder tangent to a plane. If the next element is placed at an angle, part author must provide a so called "complementary condline" (overlaping the one included in primitive) so that the condline appears properly at the right viewing incidence.
I'm also not sure that vertex normal should be calculated from condlines or from facets themselves

[Orion Pobursky]

Looks interesting, but is there a way to see it working?

Lasse may have a demo at his site.

For us, I have to pull the new code, test to see if anything broke in our code, and implement a button to enable this view.

[Travis Cobbs]

Lasse may have a demo at his site.

For us, I have to pull the new code, test to see if anything broke in our code, and implement a button to enable this view.

Would it be possible to also have a button to enable lighting? I know that it was decided that lighting off was better, but being able to enabled it would be really useful.

[Orion Pobursky]

Would it be possible to also have a button to enable lighting? I know that it was decided that lighting off was better, but being able to enabled it would be really useful.

There is lighting it's just a diffuse, ambient light. Do you want a point light?

[Lasse Deleuran]

Lasse may have a demo at his site.

For us, I have to pull the new code, test to see if anything broke in our code, and implement a button to enable this view.

I have tried to avoid breaking anything. The sample file I referred to can be accessed live on this page on brickhub

The new functions have now also been added to the standard part view, such as brickhub.org/p/85080 or a simple part like brickhub.org/p/3024


In other news, I have rebuilt the primitive generator, so that it no longer needs to know all primitives in the JavaScript file in advance. The "API" is unchanged, so it does not require any changes to how it is called. It should now also be much faster, as the 1100+ parts will now be generated on-demand, rather than on startup. The JS file is also smaller, which again results in better performance. See the new generator here. There is still a lot of primitives to be generated, but it now generates more than 50% of all official primitives!

[Orion Pobursky]

I have tried to avoid breaking anything. The sample file I referred to can be accessed live on this page on brickhub

I haven't pulled an update in a while. Your code is fine. My code, on the other hand, may not be. 👍

[Lasse Deleuran]

I haven't pulled an update in a while. Your code is fine. My code, on the other hand, may not be. 👍

Well. There is the issue with LDRStuds.js which doesn't play too well with the part fetcher. I really want that to work on this site as well, as the Generator code is beneficial for loading times, and reducing network transactions.

It requires LDRGenerator.js, but something tells me that even with that file, the fetcher has issues.

[Travis Cobbs]

There is lighting it's just a diffuse, ambient light. Do you want a point light?

From a rendering perspective, I strongly suspect that lighting has been disabled in the rendering pipeline. I guess it's possible that the lighting is enabled, and only the ambient term is included, but that seems wasteful when it should just render the polygons with their exact colors.

When I asked for lighting, I actually meant a directional light, not a point light. A directional light emulates a point light at infinite distance. It doesn't fall off over distance, and comes from a constant specific direction (typically directly out of the virtual camera in a situation like this). There would also be an ambient term to avoid having it look extremely harsh.

As an aside, the "Subdued" check box in LDView's lighting settings simply bumps up the ambient term. However, LDView does include some ambient lighting even when that check box is unchecked.

[Orion Pobursky]

There's definitely an ambient light. I checked the code before I replied. But the code I write does allow for addition of other types of lighting so I can add that when I add the other things.

[Orion Pobursky]

Lasse may have a demo at his site.

For us, I have to pull the new code, test to see if anything broke in our code, and implement a button to enable this view.

Axis visualization is now implemented.

As a side effect, the stud logo button works properly again.

[Philippe Hurbain]

Axis visualization is now implemented.

As a side effect, the stud logo button works properly again.

Nice, thanks!

[Max Murtazin]

What about adding a button that would enable primitive substitution? Would make easier to check if there are any such problems

Or we don't care about it and don't treat like an issue?

[Orion Pobursky]

What about adding a button that would enable primitive substitution? Would make easier to check if there are any such problems

Or we don't care about it and don't treat like an issue?

I believe, and Lasse can correct me if I'm wrong, that the software already does primitive sub.

[Lasse Deleuran]

I believe, and Lasse can correct me if I'm wrong, that the software already does primitive sub.

It does, using the "force" parameter that can be 8 and 48 for substituting for LO and HI res.

In the sample_part.htm file the buttons are uncommented, since I find it best to fetch the substituted primitives in advance (before building the 3D model).

Click on the yellow LO and HI res stud logo buttons to try it out: On 3022 here and observe how the substitution is forced in code using the force-parameter.

[Max Murtazin]

It does, using the "force" parameter that can be 8 and 48 for substituting for LO and HI res.

In the sample_part.htm file the buttons are uncommented, since I find it best to fetch the substituted primitives in advance (before building the 3D model).

Click on the yellow LO and HI res stud logo buttons to try it out: On 3022 here and observe how the substitution is forced in code using the force-parameter.

I see

Thing is, it's not available on the part tracker, and that's what I will be glad to see added, if there's nothing against it

[Orion Pobursky]

It does, using the "force" parameter that can be 8 and 48 for substituting for LO and HI res.

In the sample_part.htm file the buttons are uncommented, since I find it best to fetch the substituted primitives in advance (before building the 3D model).

Click on the yellow LO and HI res stud logo buttons to try it out: On 3022 here and observe how the substitution is forced in code using the force-parameter.

It's not turned on by default? The curves look smooth leading me to believe that smooth curved prims were being subbed in.

[Lasse Deleuran]

It's not turned on by default? The curves look smooth leading me to believe that smooth curved prims were being subbed in.

It should not be. To turn it on, force has to be set as an option to ldrLoader:

Code:

ldrLoader = new THREE.LDRLoader(onLoad, null, {force:8, // ... or 48 for high resolution.

// And the settings for ldrLoader is used when constructing the studs:

LDR.Studs.setStuds(ldrLoader, ...

And in order to perform substitution on other primitives, the following transformation can be made after loading (Assuming the primitives in the other resolution are present):

Code:

ldrLoader.applyOnPartTypes(function(pt) {
      if(!pt.isPart) return; // Only parts.

      function handleSubModel(sm) {
        if(sm.ID.startsWith('8/')) return; // Already substituted.
        let id2 = '8/' + sm.ID;
        if(ldrLoader.partTypes.hasOwnProperty(id2)) {
          sm.ID = id2;
        }
      }
      pt.steps.forEach(s => s.subModels.forEach(handleSubModel));
});

That is how I'm doing it - perhaps there is a prettier way.

[Orion Pobursky]

I'm not sure we're referring to the same thing.
For me, primitive substitution is replacing primitives with smooth curved version instead of the angular, segmented versions in the library. You seem to be referring to forcing the software into using lower (8 segment) or higher (48 segment) res versions of said primitives. To my eye, the software is already doing what I expect.

[Max Murtazin]

I'm not sure we're referring to the same thing.
For me, primitive substitution is replacing primitives with smooth curved version instead of the angular, segmented versions in the library. You seem to be referring to forcing the software into using lower (8 segment) or higher (48 segment) res versions of said primitives. To my eye, the software is already doing what I expect.

What exactly do you mean by "replacing primitives with smooth curved version" then? I don't think I get it

[Magnus Forsberg]

What exactly do you mean by "replacing primitives with smooth curved version" then? I don't think I get it

There are 2 different situations here
One is a proper primitive substitution. AFAIK only MLCad can do that.
The other is a mathematicaly calculated smoother curve quality. Only LDView can show that.

[Orion Pobursky]

What exactly do you mean by "replacing primitives with smooth curved version" then? I don't think I get it

Primitive substitution in it's original sense was replacing the segmented 16 or 48 primitives with true curves in POV-Ray. This has been extend to mean that all surfaces that are smoothly curve in real life are shown that way in the program.

With primitive sub:
   

Without:
   

[Magnus Forsberg]

With primitive sub:


Without:

There are no primitives used in that part, the mask. Only prim is in the not visible 3:rd subfile.
So there can't be any prim substitution in your images.

[Orion Pobursky]

There are no primitives used in that part, the mask. Only prim is in the not visible 3:rd subfile.
So there can't be any prim substitution in your images.

The difference between the 2 images is plain to see. Here's the slide from my LDraw presentation.
   

[Max Murtazin]

Primitive substitution in it's original sense was replacing the segmented 16 or 48 primitives with true curves in POV-Ray. This has been extend to mean that all surfaces that are smoothly curve in real life are shown that way in the program.

With primitive sub:


Without:

There's really nothing actually happening with geometry on this pic. It is a matter of a smooth shading

[Magnus Forsberg]

There's really nothing actually happening with geometry on this pic. It is a matter of a smooth shading

Yes, semantics.
Don't say primitive "substitution" if you mean "replacement".

[Max Murtazin]

Yes, semantics.
Don't say primitive "substitution" if you mean "replacement".

Not sure if I know how those two words differ from each other

[Orion Pobursky]

There's really nothing actually happening with geometry on this pic. It is a matter of a smooth shading

LDraw contains no data for surface normals. Said shading only happens because the normals are inferred and subbed in. Just like cylinders and cone can be inferred from the file name. It's all the same process.

[Lasse Deleuran]

Primitive substitution in it's original sense was replacing the segmented 16 or 48 primitives with true curves in POV-Ray. This has been extend to mean that all surfaces that are smoothly curve in real life are shown that way in the program.

With primitive sub:


Without:

I think the online 3D render might cause some confusion.

This is what the mask looks like in the "physical renderer":




You can see how the use of normals and UV's help to make the surface appear smooth. This is all trickery, and you can see where the trickery fails - particularly on the parts that look wrinkled, and on the top of the "kissing mouth".

Turning on UV mode highlights these issues:



 The normals (the red lines) show that some are erroneously computed at the top of the kissing mouth, causing the rendering issues:



This error can be caused either by the heuristic failing, or the part being modelled inconsistently.

I think we should have a thread where we talk about how to compute normals and UV's, since everyone seems to be doing their own thing (including me)

[Max Murtazin]

I think the online 3D render might cause some confusion.

This is what the mask looks like in the "physical renderer":




You can see how the use of normals and UV's help to make the surface appear smooth. This is all trickery, and you can see where the trickery fails - particularly on the parts that look wrinkled, and on the top of the "kissing mouth".

Turning on UV mode highlights these issues:



 The normals (the red lines) show that some are erroneously computed at the top of the kissing mouth, causing the rendering issues:



This error can be caused either by the heuristic failing, or the part being modelled inconsistently.

I think we should have a thread where we talk about how to compute normals and UV's, since everyone seems to be doing their own thing (including me)

I think that the way LDView does that particularly is very good

[Travis Cobbs]

LDraw contains no data for surface normals. Said shading only happens because the normals are inferred and subbed in. Just like cylinders and cone can be inferred from the file name. It's all the same process.

I can't comment on the WebGL renderer. However, some of the confusion here in terminology seems to perhaps be based on LDView's settings. LDView's realtime renderer has two independent settings: "Primitive Substitution", and "Smooth Curves". The former produces new triangles (which also happen to have known correct surface normals). There is a slider that allows you to control the smoothness of this generated geometry. The latter tries to infer surface normals based on the presence of conditional edge lines in the LDraw file which are treated as indicating that polygons on either side of the conditional edge are intended to be part of a smooth surface.

LDView's POV-Ray exporter also has the same two settings. In this case, "Primitive Substitution" uses truly curved POV-Ray geometric primitives for recognized LDraw primitives. These don't produce triangles at all, but mathematically generated subpixel-perfect geometric shapes. "Smooth Curves" tries to infer surface normals based on the lack of an edge line between two polygons indicating that the two polygons are intended to be part of a smooth surface.

In my opinion, surface normal generation based on a heuristic ("Smooth curves" in LDView) does not qualify as primitive substitution. One could argue that substitution is happening (a calculated surface normal at 90 degrees to the surface is being substituted with a different surface normal). However, since the 90-degree surface normal is also calculated, I think that "substitution" doesn't really apply here. Furthermore, there is no primitive involved here.

[Orion Pobursky]

I concur with this explanation including admitting to my misconception regarding this topic.

[Magnus Forsberg]

Thanks Travis, and Orion, for this clarification.

[Lasse Deleuran]

I think that the way LDView does that particularly is very good

I would really like to know what it does. From what I gather from this thread, it simply treats conditional lines to determine smooth transitions. My heuristic did the same, but that cause issues on some parts where there are overlapping hard and conditional lines, leading my heuristic to consider those for not-smooth.

[Travis Cobbs]

I would really like to know what it does. From what I gather from this thread, it simply treats conditional lines to determine smooth transitions. My heuristic did the same, but that cause issues on some parts where there are overlapping hard and conditional lines, leading my heuristic to consider those for not-smooth.

It's been a long time since I looked at the code, but LDView does apparently use edge lines to prevent smoothing. (I had forgotten about that.) Looking at my code, it only does a cursory check: if both ends of a conditional line match both ends of any edge line, the conditional line is ignored.