3D Part Preview added to Parts Tracker
(2019-07-21, 7:31)Philippe Hurbain Wrote: 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)Maybe it's because Orion is working on it, 44567 work fine now. But 40066 and subpart give a blank screen here...
Wish of the day: a 3d view button for official parts ....
(2019-07-21, 18:30)Philippe Hurbain Wrote: 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.
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
Current status is... a work in progress
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:
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
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
(2019-07-23, 7:10)Lasse Deleuran Wrote: 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?
(2019-07-23, 7:26)Magnus Forsberg Wrote: 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.
(2019-07-23, 8:06)Lasse Deleuran Wrote: 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.
(2019-07-23, 9:54)Magnus Forsberg Wrote: 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.
(2019-07-23, 17:28)Travis Cobbs Wrote: 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?
(2019-07-24, 13:54)Lasse Deleuran Wrote: 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).
RE: 3D Part Preview added to Parts Tracker
2019-07-25, 6:59 (This post was last modified: 2019-07-25, 7:01 by Lasse Deleuran. Edit Reason: debt -> depth. The buffer does not owe anything. )
2019-07-25, 6:59 (This post was last modified: 2019-07-25, 7:01 by Lasse Deleuran. Edit Reason: debt -> depth. The buffer does not owe anything. )
(2019-07-24, 17:12)Travis Cobbs Wrote: 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.)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.
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).
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!
(2019-07-28, 4:54)Orion Pobursky Wrote: 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...
(2019-07-23, 23:51)Orion Pobursky Wrote: 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.
(2019-07-28, 14:44)Lasse Deleuran Wrote: 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.
(2019-07-28, 19:42)Orion Pobursky Wrote: 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!
RE: 3D Part Preview added to Parts Tracker
2019-08-10, 12:19 (This post was last modified: 2019-08-10, 12:22 by Lasse Deleuran.)
2019-08-10, 12:19 (This post was last modified: 2019-08-10, 12:22 by 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.
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.
The 3D part preview seem to be case sensitive.
I made three new files, 3815bpw1c01 - 3815bpw3c01.
They all had code like this:
None of them showed up in the 3D viewer.
Then I changed two files: 3815bpw1c01 - 3815bpw2c01
and now they are visible in the 3D viewer.
I left the third file 3815bpw3c01 unchanged.
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
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
I left the third file 3815bpw3c01 unchanged.
(2019-09-08, 15:31)Magnus Forsberg Wrote: The 3D part preview seem to be case sensitive.
I made three new files, 3815bpw1c01 - 3815bpw3c01.
They all had code like this:
None of them showed up in the 3D viewer.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
Then I changed two files: 3815bpw1c01 - 3815bpw2c01
and now they are visible in the 3D viewer.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
I left the third file 3815bpw3c01 unchanged.
The server is case sensitive so I probably just need to lower case my url search code.
(2019-09-08, 15:31)Magnus Forsberg Wrote: The 3D part preview seem to be case sensitive.
I made three new files, 3815bpw1c01 - 3815bpw3c01.
They all had code like this:
None of them showed up in the 3D viewer.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
Then I changed two files: 3815bpw1c01 - 3815bpw2c01
and now they are visible in the 3D viewer.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
I left the third file 3815bpw3c01 unchanged.
Should be fixed now.
RE: 3D Part Preview added to Parts Tracker
2019-09-09, 11:55 (This post was last modified: 2019-09-09, 11:57 by Magnus Forsberg.)
2019-09-09, 11:55 (This post was last modified: 2019-09-09, 11:57 by Magnus Forsberg.)
(2019-09-09, 11:55)Magnus Forsberg Wrote: 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
RE: 3D Part Preview added to Parts Tracker
2019-09-09, 12:55 (This post was last modified: 2019-09-09, 20:15 by Lasse Deleuran. Edit Reason: Added info )
2019-09-09, 12:55 (This post was last modified: 2019-09-09, 20:15 by Lasse Deleuran. Edit Reason: Added info )
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
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
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.
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.
(2019-09-09, 21:22)Lasse Deleuran Wrote: 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.
(2019-07-11, 12:36)Orion Pobursky Wrote: To follow up on a couple of feature requests from the internal pre-launch thread: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...
- 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-10-25, 12:18)Philippe Hurbain Wrote: 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.
(2019-11-12, 17:10)Orion Pobursky Wrote: 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.
(2019-11-12, 19:30)Lasse Deleuran Wrote: 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
(2019-11-12, 20:08)Orion Pobursky Wrote: 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.
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.
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.
(2019-11-15, 18:38)Lasse Deleuran Wrote: 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.
« Next Oldest | Next Newest »
Users browsing this thread: 9 Guest(s)