Requesting part 76925 (Hair piece), if possible.
I cannot find it on digital bricks, would there be any other source to get the mesh from?
Probably not from the LEGO instructions app as it has to available as 3D build?
I am getting error 500 when trying to submit new parts, in both Edge and Firefox. Already deleted cookies and tried private mode, but no effect. Was able to update some existing parts yesterday, is something wrong on my side or server side?
So, continuing with my LDraw to xml converter grind, looks like I have managed to solve pretty much everything but one thing - handling sharp edges
I have tried multiple ways, but nothing seems to work. Generally, it seems I should not interpolating normals between faces that share sharp edge, but then arises problem of faces that share only 1 vertex. How this case should be approached?
Howdy!
I hope I am on the correct forum with this post
So I am trying to program a 3d viewer for my files for my website. And I got most stuff working, but now I noticed that when loading some parts, such as 4733 (Brick, Modified 1 x 1 with Studs on 4 Sides), two of the studs are oriented the wrong way (as you can see in the picture i uploaded): they are flipped on their axes, the other studs aren't though.
And so I looked into the ldr file of the part 4733 itself where the studs themselves are being rotated (line 116-120) and I noticed that the studs that are wrongly rotated on my viewer are the 2nd and 5th entry (line 117 and 120) there. And I looked at their transformation matrices and they seem kinda wrong.
So I looked into those matrices more and it kinda looks like the axis that those matrices flip (which is what the "-" does), should be on the other axis, so the entry in line 117 should actually be "1 16 10 10 0 0 1 0 -1 0 0 0 0 1 stud2a.dat" and in line 120 it should be "1 16 0 10 10 1 0 0 0 0 -1 0 1 0 stud2a.dat".
The matrices look like the creator of the ldr part switched up the matrix multiplication, like the flipping of the two axes and the invertion of the axis, cause if you take those matrices apart and switch them around (you flip the part where the "-" is as explained above) you end up with the correct transformation matrix.
Is it normal that those matrices are just wrong? Or do I not completely understand the ldraw standard in a way that you can't just take the vertices and transform them using those matrices?
Thanks for your help!
(I also have some problems with some of the "4-4ndis.dat" transformations in this and a few other parts, though I haven't looked into that yet, you can kinda see it on the attached picture though that the scaling in the y direction is wrong, might just be an error in my code who knows, I'll look into that )
(If I haven't explained some stuff properly feel free to ask!)
(If you want to look at the code I wrote for this: link, but it's not optimised yet and I've commented some stuff out since I work directly in the deployment branch and the zip library makes my automatic deployment fail xD)
The issue is here: https://library.ldraw.org/tracker/26410
* The sticker is used as a ship's plimsoll line, in portrait orientation
* The sticker is placed in landscape orientation in the sheet, only due to space limitations
* The pattern itself consists of geometrical shapes only (not font typefaces etc.) and does not have fixed orientation
As Max mentioned in the review, we need to get consensus for the orientation issue.
Which is in priority, the actual use of sticker or the placement in the sticker sheet?
I’m building a model in Studio and tried to use PartDesigner to edit the slight variation of the part that they on file but I’m not savvy enough to get it working. I’ve put in a request on the PartDesigner forum but thought I could try here too. I’m not sure how the file types work. How transferable are they from program to program?
So, I've been writing some basic LDRaw "unpacker" for some recent time, and have encountered a problem.
I'm really not sure why, but my code for transforming line type 1 makes model fall apart. It handles fine transforming all other line types, but when it comes to 1s everything breaks unless they have identity matrices for their transformations.
Checked everything, but can't find the issue. Can anybody help me with the thing?
I've been working on an experimental renderer for LDraw files. The goal is to create a performant rendering engine targeting modern GPUs. The renderer is built on top of wgpu, which uses Vulkan, DX12, or Metal depending on the platform. These APIs are newer than OpenGL and enable access to more hardware features. This includes most devices made in the last 10 years or so. This should work in the browser eventually once WebGPU is released.
The framerates can easily be several times faster than existing renderers in applications like LeoCAD, Blender, LDView, etc. My desktop with an RTX 3060 only gets 1 fps (1000+ms) per frame when viewing Datsville with standard resolution primitives and no logos on studs. I get about 6-7 fps when Fully zoomed out in ldr_wgpu. Framerates shoot up to 60-120 fps when viewing a more modest area of the scene.
While the newer graphics APIs have less CPU overhead, the biggest performance improvements come from only rendering what's actually visible each frame. This is why the framerate is highly variable as the camera moves around. ldr_wgpu performs culling at the object level. Frustum culling culls any objects that are outside the camera's viewable area. Occlusion culling culls any objects that are completely obscured by other objects. While conceptually simple, occlusion culling is hard to implement efficiently. See the README on the github repository linked below and the source code for more details. The culling is calculated each frame in real time and only requires precalculating bounding boxes and bounding spheres. When zoomed out, frustum culling no longer helps. Occlusion culling can often reduce the amount of rendered geometry by 2x-3x.
There have been a number of posts about level of detail for studs and primitives. This improves performance but greatly reduces the visual quality. Thankfully, this isn't the only way to reduce the amount of vertex processing that needs to be done by the GPU. Indexed drawing can be faster than non indexed drawing but only if duplicate vertices are merged. Modern GPUs can cache vertices with the same index. This cut the vertex processing time in half when profiling on my M1 Macbook Air.
The other main topic of discussion I've seen is BFC as a performance enhancement. Whether this helps or not is highly dependent on the situation. Backface culling happens after the vertices are processed by the vertex shader. If you have a very simple pixel/fragment shader as is common in many CAD programs, there won't be much of a performance difference. I haven't been able to measure any performance difference in my testing since I'm currently just using flat shading. The processing time each frame was easily dominated by the vertex shader. I'll reassess the impact if I implement more complicated lighting and shading in the future.
The code is designed to serve as a reference for people wanting to optimize their own renderers. I've done my best to comment any techniques and link to papers and articles where appropriate. I don't have any prebuilt executables at the moment, but you can download the code from github and compile it yourself. This requires having the Rust language toolchain installed. I plan on making this into a library that people can use for their own Rust projects eventually. There are still a number of features and improvements to address like normals and more realistic shading. The github repository will be updated periodically with new techniques and insights.
