LDraw.org Discussion Forums

A 3D part preview has been added to the part detail pages on the Parts Tracker. If your machine is WebGL capable then you can click on the 3D View link on the menu to see that part in 3D. This feature is powered by brigl (https://github.com/HazenBabcock/brigl). Please report any bugs in the Website Discussion forum.

Known bugs:
- Mouse button actions not registered if done outside the model container (e.g. if you release a mouse button with the pointer outside the model container then if you reenter the container it behaves as if you never released the button)
- Direct colors don't work properly

Thanks,
Orion

(2019-07-08, 22:40)Orion Pobursky Wrote: [ -> ]A 3D part preview has been added to the part detail pages on the Parts Tracker. If your machine is WebGL capable then you can click on the 3D View link on the menu to see that part in 3D. This feature is powered by brigl (https://github.com/HazenBabcock/brigl). Please report any bugs in the Website Discussion forum.

Known bugs:
- Mouse button actions not registered if done outside the model container (e.g. if you release a mouse button with the pointer outside the model container then if you reenter the container it behaves as if you never released the button)
- Direct colors don't work properly

Thanks,
Orion

Based on the above bugs, I’m going to switch to Lasse Deleuran’s renderer (https://github.com/LasseD/buildinginstructions.js). It doesn’t have the above issues, is more compliant with the standard, and is being actively developed. Lasse was very responsive to a feature I requested to allow the switch and was kind enough to push an update in less than a day.

I am only happy to help. And please don't hesitate adding more change request. This is my favourite way to give back to the community.


Compared to brigl, buildinginstructions.js currently lacks a nice semi-realistic renderer. I know Nicola has spent a lot of time making the one in brigl where rounded parts look almost as if there are no transitions between polygons. It is on my list to come up with a nice one for buildinginstructions.js, but currently I can only offer the flat shader which looks similar to how LEGO makes instructions.

(2019-07-09, 16:33)Lasse Deleuran Wrote: [ -> ]I am only happy to help. And please don't hesitate adding more change request. This is my favourite way to give back to the community.


Compared to brigl, buildinginstructions.js currently lacks a nice semi-realistic renderer. I know Nicola has spent a lot of time making the one in brigl where rounded parts look almost as if there are no transitions between polygons. It is on my list to come up with a nice one for buildinginstructions.js, but currently I can only offer the flat shader which looks similar to how LEGO makes instructions.

Others may disagree but I actually think the flat, instructions style is better for our uses.

(2019-07-09, 15:17)Orion Pobursky Wrote: [ -> ]Based on the above bugs, I’m going to switch to Lasse Deleuran’s renderer (https://github.com/LasseD/buildinginstructions.js). It doesn’t have the above issues, is more compliant with the standard, and is being actively developed. Lasse was very responsive to a feature I requested to allow the switch and was kind enough to push an update in less than a day.

The switch is complete on the PT. OMR will stay on Brigl for the time being.

(2019-07-10, 23:21)Orion Pobursky Wrote: [ -> ]The switch is complete on the PT. OMR will stay on Brigl for the time being.

Doesn't work on Mobile Safari or Chrome for iOS. Does work on iOS Firefox.

(2019-07-11, 1:14)Orion Pobursky Wrote: [ -> ]Doesn't work on Mobile Safari or Chrome for iOS. Does work on iOS Firefox.

There seems to be an initialization/loading problem: on my phone (Android/chrome) I need to reload page to get to the 3d view. Otherwise I get only a narrow window with close and done buttons. But after that, it works well and is fast!

(2019-07-11, 6:57)Philippe Hurbain Wrote: [ -> ]There seems to be an initialization/loading problem: on my phone (Android/chrome) I need to reload page to get to the 3d view. Otherwise I get only a narrow window with close and done buttons. But after that, it works well and is fast!

Note: sometimes it works directly without reload.

(2019-07-11, 8:39)Philippe Hurbain Wrote: [ -> ]Note: sometimes it works directly without reload.

You gave me a possible solution to the problem. I tweaked the code and now it works on mobile Safari but the zoom is wrong. I'll troubleshoot this evening.

To follow up on a couple of feature requests from the internal pre-launch thread:
- BFC Colors
- Random quad/tri colors

Both of these features are possible with Lasse's renderer and will be added at some point in the near future.

(2019-07-11, 8:39)Philippe Hurbain Wrote: [ -> ]Note: sometimes it works directly without reload.

Well my tweak didn’t work out. What’s odd is that it doesn’t work and then you refresh the page and it does. I’ll do some more google digging.

I can see a lot of the current waiting time is largely caused by the renderer guessing wrongly when trying to find the right location of a file (is the file a primitive, a part, official or unofficial). I would like to improve this and have made the following improved "guesser" available in the code base:


The first two branches are easy: If a part starts with "48/" then it is a high res primitive, and similarly for "8/" and "s/" being low-res primitives and sub parts, respectively. This is the same as the current code.

The trick is for other files: Is the file we want to load a primitive or a part?
The crude regular expression (where it says "match") tries to detect primitives. It triggers for any part name where two letters are adjacent, that is, without numbers between them.

Primitives, such as "4-4cyli.dat", "1-2disc.dat", "stud.dat" etc. all have two letters in their part id.

while parts are typically something along the lines of "3001.dat", "2461a.dat", etc. They very rarely have more than one letter next to each other (disregarding the ".dat" suffix).

This method is extremely crude, so I would like if anyone can make a better "guesser". I have tested it locally and the loading time more than halves!

(2019-07-12, 23:34)Lasse Deleuran Wrote: [ -> ]I can see a lot of the current waiting time is largely caused by the renderer guessing wrongly when trying to find the right location of a file (is the file a primitive, a part, official or unofficial). I would like to improve this and have made the following improved "guesser" available in the code base:

Code:

        if(id.startsWith('48/') || id.startsWith('8/')) {
          return [OFFICIAL_DIR + '/p/' + id,
                  UNOFFICIAL_DIR + '/p/' + id];
        }
        else if(id.startsWith('s/')) {
          return [OFFICIAL_DIR + '/parts/' + id,
                  UNOFFICIAL_DIR + '/parts/' + id];
        }
        else if(id.match(/[a-z][a-z].*\.dat/)) {
          return [OFFICIAL_DIR + '/p/' + id,
                  OFFICIAL_DIR + '/parts/' + id,
                  UNOFFICIAL_DIR + '/p/' + id,
                  UNOFFICIAL_DIR + '/parts/' + id];
        }
        else {
          return [OFFICIAL_DIR + '/parts/' + id,
                  OFFICIAL_DIR + '/p/' + id,
                  UNOFFICIAL_DIR + '/parts/' + id,
                  UNOFFICIAL_DIR + '/p/' + id];
        }

The first two branches are easy: If a part starts with "48/" then it is a high res primitive, and similarly for "8/" and "s/" being low-res primitives and sub parts, respectively. This is the same as the current code.

The trick is for other files: Is the file we want to load a primitive or a part?
The crude regular expression (where it says "match") tries to detect primitives. It triggers for any part name where two letters are adjacent, that is, without numbers between them.

Primitives, such as "4-4cyli.dat", "1-2disc.dat", "stud.dat" etc. all have two letters in their part id.

while parts are typically something along the lines of "3001.dat", "2461a.dat", etc. They very rarely have more than one letter next to each other (disregarding the ".dat" suffix).

This method is extremely crude, so I would like if anyone can make a better "guesser". I have tested it locally and the loading time more than halves!

Part of the "problem" is that for the PT I prioritize unofficial over official. Since most primitives aren't unofficial, that load has to fail before it'll try for the official version.

(2019-07-11, 1:14)Orion Pobursky Wrote: [ -> ]Doesn't work on Mobile Safari or Chrome for iOS. Does work on iOS Firefox.

This now seems to be fixed. I'm not sure what solved the problem since I only streamlined the code and didn't make any major changes.

(2019-07-12, 23:34)Lasse Deleuran Wrote: [ -> ]Primitives, such as "4-4cyli.dat", "1-2disc.dat", "stud.dat" etc. all have two letters in their part id.

while parts are typically something along the lines of "3001.dat", "2461a.dat", etc. They very rarely have more than one letter next to each other (disregarding the ".dat" suffix).

This method is extremely crude, so I would like if anyone can make a better "guesser". I have tested it locally and the loading time more than halves!

If "p" were a sub-directory of "parts" it might help...

looks very good, thank you very much.

(2019-07-09, 16:36)Orion Pobursky Wrote: [ -> ]Others may disagree but I actually think the flat, instructions style is better for our uses.

I agree with you.
Our 3D viewer is not intended to make things beautiful and hide errors, but the opposite.
It needs to show everything in great clarity, to allow us to do what the PT is for:
finding glitches.

super cool

I suggest a different approach:
why not initially send a full list of all primitives available to the client before he starts to download individual files?
then he can know that everything else is a part. no more regex guessing.
the same goes for "unofficial files vs official file":
can't the client initially get a simple list of all unofficial (or: official) files?
he could even locally cache it.
then also no more guesswork with regexes would be needed.
Of course, if these lists get very large, the benefit would be spoiled, but currently I think:
- the download of such lists could be faster than N failed URL accesses
- the downloaded list could be cached on client side maybe
- it could be sent in compressed form
- it could be pre-calculated on the server

While I am writing this, I come to another idea:
the server knows everything about every file.
it knows what is a primitive and what is a part etc.,
and which one is official and which one is unofficial.
Thus, when a client requests to download some file, say 777.dat,
the server can help the client and compile a list of "meta" info for the client, telling him
which file is official and which one not, and the folder in which it is to be found.
The client would access something like
www.ldraw.org/get_list_of_required_files_for?777.dat
, and the server would reply with a JSON which could look like
This reply will make it easy for the client to construct the URL for downloading the required files.

Those are all great ideas! It should be straight forward to make the guesser prioritize unofficial primitives over everything else when an unofficial element is being shown.

I have dug further into the idea of caching primitives client-side. Caching unofficial parts and primitives is a little troublesome since they might change, but caching official parts and primitives should be safe, right? This is what the ClientStorage.js does. I have updated the sample file to use this. It builds an "IndexedDB" store on the client with compressed geometries which are fetched before the code attempts to make a server call.

There is also an even more extreme measure (which can be turned off, of course): LDRGenerator.js. This generates the simplest of primitives directly in the code (like PrimGen2) and is even faster than the IndexedDB! Currently only 24 primitives are supported here, but this approach has great potential.

Oh. I almost forgot. The code not also supports high contrast studs and studs with logos (all 5 types of logos that are found in the LDraw unofficial primitives directory)


High contrast and logos can be configured using simple parameters:

ldrOptions.studHighContrast = 0; // Set to 1 for high contrast

ldrOptions.studLogo = 0; // 0 for no logo, 1 to 5 for logo types 1 to 5


I apologize for any typos. I was up the whole night because I got too deep into this... and it is quite fun.

(2019-07-13, 5:07)Michael Horvath Wrote: [ -> ]If "p" were a sub-directory of "parts" it might help...

That's never going to happen. Aside from breaking every almost every model, pushing such a massive change through the PT would be nothing short of insane.

(2019-07-11, 12:36)Orion Pobursky Wrote: [ -> ]To follow up on a couple of feature requests from the internal pre-launch thread:
- BFC Colors
- Random quad/tri colors

Both of these features are possible with Lasse's renderer and will be added at some point in the near future.

This is now implemented.

The icons could be better. The choices are from these:
https://fontawesome.com/icons?d=gallery&m=free
or some sending me good quality substitutes.

(2019-07-13, 7:21)Steffen Wrote: [ -> ]The client would access something like
www.ldraw.org/get_list_of_required_files_for?777.dat
, and the server would reply with a JSON

I'll see what I can implement. This may take some time.

(2019-07-13, 4:54)Orion Pobursky Wrote: [ -> ]This now seems to be fixed. I'm not sure what solved the problem since I only streamlined the code and didn't make any major changes.

With the recent changes, mobile is broken again. Ugh.

I don't know if that would be feasible, but instead of random coloring per facet, I'd find more useful a coloring per entity (single color for a primitive or subpart)

Maybe a "Paint brush" as Random colour-button, and a green "Leaf"  as BFC-button ?

(2019-07-09, 15:17)Orion Pobursky Wrote: [ -> ]Based on the above bugs, I’m going to switch to Lasse Deleuran’s renderer

There's one thing that I don't like with this renderer.
The center of rotation seems to fixed to the center of the window, instead of using the center of the part/model. If I move the part/model sideways and then want to rotate it, I have to guess and move it back into the center of the window. If I don't, the part/model will move around in a big circle, in the window. Is it possible to have a "re-center" button?

(2019-07-15, 2:06)Orion Pobursky Wrote: [ -> ]With the recent changes, mobile is broken again. Ugh.

Clarification: only broken on Mobile Safari.

(2019-07-15, 18:20)Philippe Hurbain Wrote: [ -> ]I don't know if that would be feasible, but instead of random coloring per facet, I'd find more useful a coloring per entity (single color for a primitive or subpart)

I'm sure it's possible but Lasse will need to chime in about how to do it.

(2019-07-15, 18:45)Magnus Forsberg Wrote: [ -> ]Maybe a "Paint brush" as Random colour-button, and a green "Leaf"  as BFC-button ?

Better than my choices. Done.

(2019-07-16, 2:00)Orion Pobursky Wrote: [ -> ]I'm sure it's possible but Lasse will need to chime in about how to do it.

A quick and dirty approach to this is to use the same type of method overwriting as for the other modes:


This leaves each type of part with a random color. All studs on a brick will thus be colored the same random color.

If you want each part to have its own color (such as each stud on a brick in its own color) then additional functions have to be overwritten.

(2019-07-16, 6:41)Lasse Deleuran Wrote: [ -> ]A quick and dirty approach to this is to use the same type of method overwriting as for the other modes:

Code:

  var acceptedColors = [1, 2, 4, 5, 13, 14, 19, 22, 25, 27, 69, 71, 72, 73, 74, 77, 288, 308, 484];
   THREE.LDRStep.prototype.addSubModel = function(subModel) {
     subModel.colorID = acceptedColors[Math.floor(Math.random() * acceptedColors.length)];
     this.subModels.push(subModel);
   }

This leaves each type of part with a random color. All studs on a brick will thus be colored the same random color.

If you want each part to have its own color (such as each stud on a brick in its own color) then additional functions have to be overwritten.

I think what is wanted is the colors for all the quads/tri/and subparts in the top level file to be randomized.

(2019-07-16, 13:50)Orion Pobursky Wrote: [ -> ]I think what is wanted is the colors for all the quads/tri/and subparts in the top level file to be randomized.

The following should cover that scenario:


It took me a bit longer to come up with this solution that I would like to admit!

This is now implemented. Loading speed has greatly improved.

(2019-07-18, 6:42)Lasse Deleuran Wrote: [ -> ]The following should cover that scenario:

Code:

      // Half-Harlequin-mode:
      var acceptedColors = [1, 2, 4, 5, 13, 14, 19, 22, 25, 27, 69, 71, 72, 73, 74, 77, 288, 308, 484];
      THREE.LDRStep.prototype.addSubModel = function(subModel) {
        subModel.colorID = acceptedColors[Math.floor(Math.random() * acceptedColors.length)];
        this.subModels.push(subModel);
      }
      LDR.LDRGeometry.prototype.fromPartType = function(loader, pt) {
        loader.getMainModel().IS_MAIN_MODEL = true;
        let geometries = [];
        if(pt.steps.length === 0) {
          console.warn("No steps in " + pt.ID);
          return; // Empty - just make empty.
        }
        if(pt.IS_MAIN_MODEL) { // Harlequin the triangles and quads:
          pt.steps.forEach(step => {
            step.quads.forEach(quad => quad.colorID = acceptedColors[Math.floor(Math.random() * acceptedColors.length)]);
            step.triangles.forEach(triangle => triangle.colorID = acceptedColors[Math.floor(Math.random() * acceptedColors.length)]);
          });
        }

        pt.steps.forEach(step => {
            let g = new LDR.LDRGeometry();
            g.fromStep(loader, step);
            geometries.push(g);
        });

        this.replaceWith(LDR.mergeGeometries(geometries));
      }

It took me a bit longer to come up with this solution that I would like to admit!

I've implemented this but the rendering has errors:

[attachment=3849]

Looks like BFC coloring is fooled by noclip statements. See:
https://www.ldraw.org/cgi-bin/ptdetail.c...231p01.dat
https://www.ldraw.org/cgi-bin/ptdetail.c...69bpz4.dat
https://www.ldraw.org/cgi-bin/ptdetail.c...086ps1.dat
These files show 3 different types of wrong rendering.

Also: I have had problems with zooming level (goes to extreme zoom in) when rapidly switching between rendering modes and rotate view. So far I've not been able to reproduce this reliably.

(2019-07-18, 22:38)Orion Pobursky Wrote: [ -> ]I've implemented this but the rendering has errors:

That's no good! Can you please share the file you are viewing?

I am unable to replicate the issue with the files I have on hand for testing.

EDIT: I found a part that fails. I will be able to look at this once I get home tonight.

(2019-07-19, 7:00)Lasse Deleuran Wrote: [ -> ]That's no good! Can you please share the file you are viewing?

I am unable to replicate the issue with the files I have on hand for testing.

EDIT: I found a part that fails. I will be able to look at this once I get home tonight.

The one pictured above is this one:

https://www.ldraw.org/cgi-bin/ptdetail.c...675ps1.dat

(2019-07-19, 6:44)Philippe Hurbain Wrote: [ -> ]Looks like BFC coloring is fooled by noclip statements. See:
https://www.ldraw.org/cgi-bin/ptdetail.c...231p01.dat
https://www.ldraw.org/cgi-bin/ptdetail.c...69bpz4.dat
https://www.ldraw.org/cgi-bin/ptdetail.c...086ps1.dat
These files show 3 different types of wrong rendering.

I already noticed this and PM'd Lasse

(2019-07-19, 6:44)Philippe Hurbain Wrote: [ -> ]Also: I have had problems with zooming level (goes to extreme zoom in) when rapidly switching between rendering modes and rotate view. So far I've not been able to reproduce this reliably.

This is probably caused by 2 bits of code trying to run at the same time since part loading is asynchonous.

(2019-07-19, 12:20)Orion Pobursky Wrote: [ -> ]The one pictured above is this one:

https://www.ldraw.org/cgi-bin/ptdetail.c...675ps1.dat

This, in combination with the 'half harlequin' mode turned out to be a great stress test of the geometry-optimization for the renderer. I have pushed a fix of 'js/LDRGeometries' to master.

Content of the bug fix: This diff on GitHub

(2019-07-20, 11:12)Lasse Deleuran Wrote: [ -> ]This, in combination with the 'half harlequin' mode turned out to be a great stress test of the geometry-optimization for the renderer. I have pushed a fix of 'js/LDRGeometries' to master.

Content of the bug fix: This diff on GitHub

I pulled the latest updates and no errors that I can see.

I've compensated for the extra primitives added by the setStuds method in my path prefretch script and started playing around with this.

Looks good however the rounded stud tops don't render well in the flat, non-shiny, instructions-style format. High contrast also works quite well. 

I did get a "call stack to large" when trying to render parts with lots of studs (like baseplates) in quality 4 or 5. Example:
https://www.ldraw.org/cgi-bin/ptdetail.c.../10p01.dat
(Note: I have quality set at 0 on the PT so you'll have to download and use this part elsewhere to get the error)

Also, for PT purposes, can you add a non-rounded stud with line logo option?

(2019-07-20, 15:07)Orion Pobursky Wrote: [ -> ]I pulled the latest updates and no errors that I can see.

Primitives inside the subfile gets random colours. Don't think that was wanted/intended?

[attachment=3852]

Here, the subfile is orange, and the primitives inside it is randomized.
https://www.ldraw.org/cgi-bin/ptdetail.c...85p137.dat

(2019-07-20, 15:07)Orion Pobursky Wrote: [ -> ]I pulled the latest updates and no errors that I can see.

Excellent. I am looking into the BFC issue not. It is regarding BFC NOCLIP. The simple 'hack' to show BFC might be a bit too simple.

(2019-07-20, 15:33)Magnus Forsberg Wrote: [ -> ]Primitives inside the subfile gets random colours. Don't think that was wanted/intended?



Here, the subfile is orange, and the primitives inside it is randomized.
https://www.ldraw.org/cgi-bin/ptdetail.c...85p137.dat

Ah. That makes a lot of sense. I have pushed a new sample file where only the top level sub files are given random colors:

https://github.com/LasseD/buildinginstru...lequin.htm

(2019-07-20, 15:50)Lasse Deleuran Wrote: [ -> ]Ah. That makes a lot of sense. I have pushed a new sample file where only the top level sub files are given random colors:

https://github.com/LasseD/buildinginstru..._harlequin.

Implemented. No errors

See also my comments about studs at the bottom of the thread.

(2019-07-20, 15:19)Orion Pobursky Wrote: [ -> ]I've compensated for the extra primitives added by the setStuds method in my path prefretch script and started playing around with this.

Looks good however the rounded stud tops don't render well in the flat, non-shiny, instructions-style format. High contrast also works quite well. 

I did get a "call stack to large" when trying to render parts with lots of studs (like baseplates) in quality 4 or 5. Example:
https://www.ldraw.org/cgi-bin/ptdetail.c.../10p01.dat
(Note: I have quality set at 0 on the PT so you'll have to download and use this part elsewhere to get the error)

Also, for PT purposes, can you add a non-rounded stud with line logo option?

Are you thinking of a hard edge stud like type 1 but with the raises sides like type 4?

(2019-07-20, 17:57)Lasse Deleuran Wrote: [ -> ]Are you thinking of a hard edge stud like type 1 but with the raises sides like type 4?

No. A combo of stud.dat with logo.dat.

(2019-07-20, 16:30)Orion Pobursky Wrote: [ -> ]See also my comments about studs at the bottom of the thread.

Overall, works great and is damn fast! But for some reason I see nothing for this part https://www.ldraw.org/cgi-bin/ptdetail.c...44567a.dat (b version too)
Wish of the day: a 3d view button for official parts ....

(2019-07-20, 18:12)Orion Pobursky Wrote: [ -> ]No. A combo of stud.dat with logo.dat.

That would be the one you get when you set the stud type to 1, right? (stud.dat is the one with square sides, while logo.dat is the single line edge draw type)