3D Part Preview added to Parts Tracker

[Gerald Lasser]

Wish of the day: a 3d view button for official parts ....

Yesss!

[Orion Pobursky]

Yesss!

This is on the list but I have to figure out how I want to implement.

[Philippe Hurbain]

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 ....

Maybe it's because Orion is working on it, 44567 work fine now. But 40066 and subpart give a blank screen here...

[Orion Pobursky]

Maybe it's because Orion is working on it, 44567 work fine now. But 40066 and subpart give a blank screen here...

I haven't done anything since yesterday. There's appear to be a bug in my path prefetch script that I can't troubleshoot on my phone so it'll have to wait until I'm home tonight.

[Johann Eisner]

This is on the list but I have to figure out how I want to implement.

??

[Orion Pobursky]

Maybe it's because Orion is working on it, 44567 work fine now. But 40066 and subpart give a blank screen here...

There's an error in this part (actually the subpart 40066s01). It references an invalid file which causes the renderer to fail.

[Orion Pobursky]

You're right. For some reason I though it was different.

[Orion Pobursky]

Ability to toggle stud logos on and off is now added.

[Lasse Deleuran]

An update on the BFC color coding issue. There is an optimization in the way buildinginstructions.js generates the triangles shown on screen which stands in the way of proper color coding for BFC when there is a mix of culled and not culled primitives. I am currently writing a new triangle generator which circumvents this issue. However. It is still a work in progress. Hopefully to be finished this week. 

Current status is... a work in progress 

[Lasse Deleuran]

I have now updated the geometry handling on buildinginstructions.js so that it no longer has the issue with non-culled sub models being merged with ones that are culled (this caused both sub models to not be culled in order to ensure no triangles were lost). 

There is a new Javascript file that should be included when showing BFC: js/LDRBFCGeometries.js

Once included, BFC can be turned on by running:

Code:

// Enable BFC:
      THREE.LDRPartType.prototype.ensureGeometry = function(loader) {
        if(!this.geometry) {
          this.geometry = new LDR.BFCGeometry();
          this.geometry.fromPartType(loader, this);
        }
      }

And rebuilding.


That said. The sample file is still a bit odd to my eye. Does anyone know if it is on purpose that one of the transparent sections has more surfaces, hence the darker hue of the transparent section? This is 44375bps0.dat

[Magnus Forsberg]

Does anyone know if it is on purpose that one of the transparent sections has more surfaces, hence the darker hue of the transparent section?

I don't see any error in the code of that part, but also doesn't understand where you think you see an error. This part should have four transparent sections, three LBG sections and one DBG section. Could you place an arrow or a ring around the issue?

[Lasse Deleuran]

I don't see any error in the code of that part, but also doesn't understand where you think you see an error. This part should have four transparent sections, three LBG sections and one DBG section. Could you place an arrow or a ring around the issue?

Check out the darkness of the top left and bottom right windows. in the picture. They show darker panes than the rest of the transparent sections. This is due to additional transparent (color 40) triangles being drawn on top of each other.

Either there are multiple parts lying on top of each other, or I have made an error in the renderer.

[Magnus Forsberg]

Either there are multiple parts lying on top of each other, or I have made an error in the renderer.

I can't see anything wrong in the part, or its subparts, that would create extra surfaces. The four trans window panes are created by using the same subfile four times, one for each pane. If there was something wrong, you ought to have the same error in all four.

[Lasse Deleuran]

I can't see anything wrong in the part, or its subparts, that would create extra surfaces. The four trans window panes are created by using the same subfile four times, one for each pane. If there was something wrong, you ought to have the same error in all four.

This tells me that the renderer is making a mistake. I will look into it.

[Travis Cobbs]

This tells me that the renderer is making a mistake. I will look into it.

I don't see the problem when viewing the part from a similar angle in LDView:

   

--Travis

[Orion Pobursky]

This is now implemented

[Travis Cobbs]

This is now implemented

Turning on BFC highlighting on 44375bps0 no results in no display. (There is initially no update, but when you then spin, it disappears.)

[Orion Pobursky]

Turning on BFC highlighting on 44375bps0 no results in no display. (There is initially no update, but when you then spin, it disappears.)

Seems to work on my phone. Try a ctrl-shift-r to reload the cached scripts.

[Lasse Deleuran]

I don't see the problem when viewing the part from a similar angle in LDView:



--Travis

I have found the issue. It is due to how WebGL handles drawing order. I have reduced the error to these 3 transparent quads for an example:



There is one big quad in the background, and two smaller quads flying in front of it. All in the same color (trans black color 40).

On the top of the right side you can see they are in the same geometry, so they are belonging to the same "Object" being drawn by WebGL.

The reason why only one of them works correctly is their order in the object: The small left triangle comes first, then the big one, and the failing one to the right comes last.

WebGL only renders transparent triangles correctly when they are drawn before the stuff behind. This is the reason why I am separating transparent and opaque stuff in the code base. Unfortunately I do not know how to fix this issue without either making all transparent geometries not culled, or do some crazy inefficient sorting before rendering.

So what do you guys think? Is this a big enough issue to reduce efficiency by not culling transparent elements, or should it just be left like this?

[Orion Pobursky]

How noticable can these errors be? If it's something that will be noticed only for those who know about the error or only under extreme zoom then I think it's a non-issue.

[Travis Cobbs]

WebGL only renders transparent triangles correctly when they are drawn before the stuff behind. This is the reason why I am separating transparent and opaque stuff in the code base. Unfortunately I do not know how to fix this issue without either making all transparent geometries not culled, or do some crazy inefficient sorting before rendering.

So what do you guys think? Is this a big enough issue to reduce efficiency by not culling transparent elements, or should it just be left like this?

I've never used WebGL, but for rasterizer-based 3D rendering in general (and OpenGL in specific), you typically need to draw the transparent objects last, not first. That's the only way opaque geometry behind them will be visible through them. Furthermore, you typically want to render the transparent geometry from back to front, not from front to back. Once again, that's so that the transparent stuff in back is visible through the stuff in front. (There is a technique called depth peeling that allows you to render transparent geometry in arbitrary order, but it has a maximum number of overlapping transparent polygons that can be drawn correctly.)

LDView sorts transparent polygons by default (although it does so in multiple threads), and the performance is usually acceptable, since the total number of transparent polygons is usually manageable. Certainly for displaying parts, sorting should be plenty fast. One thing that might improve the results for parts without requiring sorting is to disable Z-buffer writes during transparent polygon drawing. (Leave depth testing enabled, but don't update the depth buffer during transparent drawing.) With non-lit transparent polygons that are the same color, this would (I think) completely fix the problem. If two different colored transparent polygons overlap, the result could be wrong (although it might still be better than what you have now; you'd have to test).

[Lasse Deleuran]

I've never used WebGL, but for rasterizer-based 3D rendering in general (and OpenGL in specific), you typically need to draw the transparent objects last, not first. That's the only way opaque geometry behind them will be visible through them. Furthermore, you typically want to render the transparent geometry from back to front, not from front to back. Once again, that's so that the transparent stuff in back is visible through the stuff in front. (There is a technique called depth peeling that allows you to render transparent geometry in arbitrary order, but it has a maximum number of overlapping transparent polygons that can be drawn correctly.)

LDView sorts transparent polygons by default (although it does so in multiple threads), and the performance is usually acceptable, since the total number of transparent polygons is usually manageable. Certainly for displaying parts, sorting should be plenty fast. One thing that might improve the results for parts without requiring sorting is to disable Z-buffer writes during transparent polygon drawing. (Leave depth testing enabled, but don't update the depth buffer during transparent drawing.) With non-lit transparent polygons that are the same color, this would (I think) completely fix the problem. If two different colored transparent polygons overlap, the result could be wrong (although it might still be better than what you have now; you'd have to test).

You are right. It must be drawn back-to-front. And thanks for the pointers. I will look into the depth buffer fix and other algorithms to improve this aspect. 

My biggest issue is performance. I am used to write in C++, so the performance aspects of this all being written in Javascript (and GLSL) is an adventure!

[Orion Pobursky]

Ok, Steffen, I relent (mostly because I figured out how to do it without affecting non-WebGL clients). You can now click the image to get the 3d View and browsers without WebGL will behave normally.

[Philippe Hurbain]

Ok, Steffen, I relent (mostly because I figured out how to do it without affecting non-WebGL clients). You can now click the image to get the 3d View and browsers without WebGL will behave normally.

Convenient, thanks!
Otherwise, I can't 3D view some obsoletized shortcuts, such as https://www.ldraw.org/cgi-bin/ptdetail.cgi?s=4100338 (blank window). Not that it bothers me much, but...

[Lasse Deleuran]

Seems to work on my phone. Try a ctrl-shift-r to reload the cached scripts.

I have found the hack of adding unused query parameters with the timestamp of files works fairly well to avoid browser caching of updated files.

So instead of "file.js", the URL is "file.js?t=2019-07-30-13-44.

The need comes especially from mobile platforms. As an example. I am unable to hard refresh on iPhone standard browser without deleting all browser data.

[Orion Pobursky]

The need comes especially from mobile platforms. As an example. I am unable to hard refresh on iPhone standard browser without deleting all browser data.

Fir mobile safari it easy. Just long press on the reload button and choose "reload without content blockers". This'll refresh everything for the page.

[Lasse Deleuran]

Fir mobile safari it easy. Just long press on the reload button and choose "reload without content blockers". This'll refresh everything for the page.

OK. That is the last time I'm taking advice from google. I ended up implementing the timestamp trick site-wide to prevent this issue! 

[Lasse Deleuran]

I have added stud logos to the following stud types in the library (the change is pushed to the latest version of the master branch of buildinginstructions.js):

studp01
studel
studa
stud10
stud15
stud17
stud13
stud6


Unfortunately this has surfaced some issues. I recall having read that stud logos should not be mirrored, even when found on mirror geometries. If I can find where this is written, then I can try to "unmirror" logos that are shown.

The issues are documented here: https://github.com/LasseD/buildinginstru.../issues/22

And I am copying them below:


Adding logos on studp01.dat reveals issue with stud rotation on u1454p01.dat
https://www.ldraw.org/parts/official-par...d=u1454p01
See: https://brickhub.org/p/u1454p01



Adding logos on stud15.dat reveals issues with stud rotation on 92947.dat
See: https://brickhub.org/p/92947



Adding logos on stud17.dat reveals the following issues:
For 6042.dat:
https://www.ldraw.org/parts/official-par...artid=6042
using:
https://www.ldraw.org/parts/official-par...=s/6042s01
Logos are only present in the top studs. They all face the same direction ('L' toward the sideways stud section). With s/6042s01.dat being used mirrored, the logos are incorrectly shown.
See: https://brickhub.org/p/6042
For 6032.dat:
https://www.ldraw.org/parts/official-par...=s/6042s01
using:
https://www.ldraw.org/official-part-look...032s01.dat
There should be a logo in the inner stud (The letters 'L' and 'O' are visible in the left side of the real part due to a molding point, while the right inner stud contains an encircled 'C'). Due to no logo being completely visible on the real part, my vote is for not changing the LDraw part to use stud17.dat.
See: https://brickhub.org/p/6032



Adding logos on stud13.dat shows an issue with 4773a.dat where mirroring and rotations result in stud logos being shown wrongly.
See: https://brickhub.org/p/4773a


Adding logos on stud6.dat shows an issue with 17485.dat where rotations result in stud logos being shown wrongly.
https://www.ldraw.org/parts/official-par...rtid=17485
See: https://brickhub.org/p/17485


Edit: If you do not see logos in the brickhub pages, then please visit https://brickhub.org/i/p.php?model=457 (a random parts list) and press the "LEGO" button in the settings below. After this the logos should appear on parts pages as well. I am currently looking into getting this functionality copied to the parts pages so you don't need this workaround.

[Magnus Forsberg]

The 3D part preview seem to be case sensitive.

I made three new files, 3815bpw1c01 - 3815bpw3c01.
They all had code like this:

Code:

1 16 0 0 0 1 0 0 0 1 0 0 0 1 3815b.DAT
1 16 0 12 0 1 0 0 0 1 0 0 0 1 3816bpw3.DAT
1 16 0 12 0 1 0 0 0 1 0 0 0 1 3817bpw3.DAT

None of them showed up in the 3D viewer.

Then I changed two files: 3815bpw1c01 - 3815bpw2c01

Code:

1 1 0 0 0 1 0 0 0 1 0 0 0 1 3815b.dat
1 16 0 12 0 1 0 0 0 1 0 0 0 1 3816bpw2.dat
1 16 0 12 0 1 0 0 0 1 0 0 0 1 3817bpw2.dat

and now they are visible in the 3D viewer.

I left the third file 3815bpw3c01 unchanged.

[Philippe Hurbain]

Ah, this explains why sometimes I see nothing... That said, file names in official library are supposed to be lower case and referenced this way (but a lot of file contain capital letters). LDPE issues a warning for that.

[Orion Pobursky]

The 3D part preview seem to be case sensitive.

I made three new files, 3815bpw1c01 - 3815bpw3c01.
They all had code like this:

Code:

1 16 0 0 0 1 0 0 0 1 0 0 0 1 3815b.DAT
1 16 0 12 0 1 0 0 0 1 0 0 0 1 3816bpw3.DAT
1 16 0 12 0 1 0 0 0 1 0 0 0 1 3817bpw3.DAT

None of them showed up in the 3D viewer.

Then I changed two files: 3815bpw1c01 - 3815bpw2c01

Code:

1 1 0 0 0 1 0 0 0 1 0 0 0 1 3815b.dat
1 16 0 12 0 1 0 0 0 1 0 0 0 1 3816bpw2.dat
1 16 0 12 0 1 0 0 0 1 0 0 0 1 3817bpw2.dat

and now they are visible in the 3D viewer.

I left the third file 3815bpw3c01 unchanged.

The server is case sensitive so I probably just need to lower case my url search code.

[Orion Pobursky]

The 3D part preview seem to be case sensitive.

I made three new files, 3815bpw1c01 - 3815bpw3c01.
They all had code like this:

Code:

1 16 0 0 0 1 0 0 0 1 0 0 0 1 3815b.DAT
1 16 0 12 0 1 0 0 0 1 0 0 0 1 3816bpw3.DAT
1 16 0 12 0 1 0 0 0 1 0 0 0 1 3817bpw3.DAT

None of them showed up in the 3D viewer.

Then I changed two files: 3815bpw1c01 - 3815bpw2c01

Code:

1 1 0 0 0 1 0 0 0 1 0 0 0 1 3815b.dat
1 16 0 12 0 1 0 0 0 1 0 0 0 1 3816bpw2.dat
1 16 0 12 0 1 0 0 0 1 0 0 0 1 3817bpw2.dat

and now they are visible in the 3D viewer.

I left the third file 3815bpw3c01 unchanged.

Should be fixed now.

[Magnus Forsberg]

It looks like something is wrong in the viewer. The random colour button also randomize some of the vertices and break the model geometry.

[Lasse Deleuran]

It looks like something is wrong in the viewer. The random colour button also randomize some of the vertices and break the model geometry.

That sounds bad. Do you have a sample file where this is observed?

[Magnus Forsberg]

That sounds bad. Do you have a sample file where this is observed?

I've seen it on two different pc's, on two different parts, 44301a.dat and 93575.dat. These are recently updated parts on the PT.

[Orion Pobursky]

That sounds bad. Do you have a sample file where this is observed?

Can confirm. Just use any part on the tracker. The more triangles, the better.

[Philippe Hurbain]

I've seen it on two different pc's, on two different parts, 44301a.dat and 93575.dat. These are recently updated parts on the PT.

Here too. Especially impressive for https://www.ldraw.org/cgi-bin/ptdetail.c.../u9479.dat

[Lasse Deleuran]

Excellent. Thanks. I see it now too. I will make a local copy and start debugging this evening.

Edit: It seems to be due to poor vertex attribute construction. Unfortunately the bug only appears intermittendly once I reduce the input :S


[.WebGL-0x7fbd710dd000]GL ERROR :GL_INVALID_OPERATION : glDrawElements: attempt to access out of range vertices in attribute 0

[Lasse Deleuran]

Bug identified and fixed in latest push to master branch.

I made the mistake of using the same markers for line vertices and triangle vertices, resulting in triangle vertices being marked as already being in use when they were not. This sometimes resulted in fancy gradient colors, and sometimes complete failures of texture loading.

Thanks for the bus report. This error would otherwise have affected all multi-colored parts.

[Orion Pobursky]

Bug identified and fixed in latest push to master branch.

I made the mistake of using the same markers for line vertices and triangle vertices, resulting in triangle vertices being marked as already being in use when they were not. This sometimes resulted in fancy gradient colors, and sometimes complete failures of texture loading.

Thanks for the bus report. This error would otherwise have affected all multi-colored parts.

Update pulled to server. Everything appears to be fixed.

[Philippe Hurbain]

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.

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...

[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 do not know what will be the best place to have these requests, so I have added it to the issues list here: https://github.com/LasseD/buildinginstructions.js/issues/26

I have also found that the 'physical' viewer has found some issues with parts - particularly when lines of type 2 and 5 overlap, when vertices do not overlap properly, and such. 

[Magnus Forsberg]

The "Toggle stud logos"- button doesn't work anymore. No logo is added when I click on it.
(Win 10 1903 + Firefox (updated), but I saw this prior to the latest Win update.)

[Philippe Hurbain]

The "Toggle stud logos"- button doesn't work anymore. No logo is added when I click on it.
(Win 10 1903 + Firefox (updated), but I saw this prior to the latest Win update.)

Confirmed with another OS/browser

[Orion Pobursky]

Confirmed with another OS/browser

Thanks for the report. The way studs are handled has changed so I'll have to retool my stud toggle code. This should be fixed by tomorrow.

[Lasse Deleuran]

Thanks for the report. The way studs are handled has changed so I'll have to retool my stud toggle code. This should be fixed by tomorrow.

Sorry about that. I thought I had tested this back when the changes were made (see my post with all the stud types)

Please tell me if there are any issues with the change.

[Orion Pobursky]

Sorry about that. I thought I had tested this back when the changes were made (see my post with all the stud types)

Please tell me if there are any issues with the change.

I knew about the change but didn’t implement because I forgot. I had planned to centralize all the render code into one file but real life got in the way and I didn’t finish that either. I’ll have much more free time in the next few weeks to work on my website todo list

[Orion Pobursky]

I knew about the change but didn’t implement because I forgot. I had planned to centralize all the render code into one file but real life got in the way and I didn’t finish that either. I’ll have much more free time in the next few weeks to work on my website todo list

Still working in this. The limited amount of tweaking I did yesterday didn't solve the problem.

[Lasse Deleuran]

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.

[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 haven't gotten back to this yet. I'll have time this evening to work on a fix.