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?

Link to the code: https://pastebin.com/tcy91ih2

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.

https://github.com/ScanMountGoat/ldr_wgpu

   

A couple of admin items:

- I'll be troubleshooting some user's trouble with the PT logging them in based on their forum credentials. This may involve me force logging out everyone from the forums.

- I'm going to add a validation to prevent submitting a part that has missing references. Fixing these takes times away from working on important things. Parts should be submitted in a "ready to go condition" and that hasn't been happening in some cases.

Is it possible to get this one made? 

3069pb0079 Tile 1 x 2 with Groove with Elder Futhark Runes Logogram (LEGO) Pattern

You will be amazed at what bricks you will find used in older building instructions from the LEGO Club sometimes. 

Is there a way to quickly find and select rotation axes in LDCAD?

Right now I have to manually move the selection center to the preferred position then select the right axis and rotate the part.
If I later on another day with another model use the same part again I have again manually find the right position of the selection center,
which takes some time and is very repetitive and also quite fiddly. Is there some way to save this information of where the rotation axis is?
Especially for "natural" / "real life rotation axes" it would be convenient if there was a move selection center to rotation axis option (if selection is a single part).

"natural rotation axis" would be e.g. the connection (axis) of a hinge.


standard selection center (and rotation axes)


moved selection center to "natural rotation axis"


Also what is the best and quickest way to do this if the selection is a submodel ?
I know I can again move the selection center manually - but most of the time I actually want to rotate the whole submodel
around the "natural rotation axis" of a part of the submodel.
I would like to set the selection center of the sub model just by clicking on that part (in nested mode? ) and then choose set to rotation axis and
then the selection center of that part becomes a selection center of the whole sub model and also setting the grid in the right way so choosing the part/submodel rotate option
rotates around the right axis-  in the main model space.

I wonder if a macro/script would be able to do this and if that could become fully part of LDCAD.

Because currently it takes way to long for me to rotate parts around commonly used axis (what I call "natural rotation axes")
and also whole groups/submodels/multiple bricks selections.

I hope it is understandable what I want.

I'd like to drop the CMF pattern categories. 

As a broader proposal, I'd like to drop pattern categories completely. 

I feel keywords better suited, many patterns cross categories, and we've already ignored the rules in some cases (Nexo shields). Additionally it is felt that choosing the "correct" code is a source of confusing among new authors.

Do anyone here has a stand-alone LDR to Collada converter, and willing to share it's code? Need one for a little project of mine

Hi all,

Since LEGO Bricktales came out I was intrigued by the models and builds in the game.
I really enjoyed playing it too. The whole concept of building things in game is quite clever.
Though the building mechanisms and controls are very clumsy. And if you are, like me, used to LDCad, very difficult to master.

The various worlds and levels are very cleverly build IMHO and I am trying to remake some of them.
There are some really nice builds in it.

Here is some work on 3 vignets from the Jungle World
The Plane Crash is complete
The one with the Monkey statues and the snake is 99% complete
The Skull waterfall is not yet complete, but getting there. A few rock formations to do.

Enjoy and LMKWYT


  Jungle Plane Crash_Copy.jpg (Size: 43.9 KB / Downloads: 52)


  Jungle Snake and Monkey_Copy.jpg (Size: 43.99 KB / Downloads: 53)


  Jungle Skull Waterfall_Copy.jpg (Size: 40.56 KB / Downloads: 53)

P.s. I also made the Dragon from the Medieval world
https://forums.ldraw.org/thread-26926.html

Attached Files

  Jungle Plane Crash.mpd (Size: 203.25 KB / Downloads: 10)
  Jungle Skull Waterfall.mpd (Size: 229.59 KB / Downloads: 9)
  Jungle Snake and Monkey.mpd (Size: 250.48 KB / Downloads: 11)

There are a number of parts on the Part Tracker, and perhaps also some offical, that should be adapted and become Part Flexible_Section.
Like the Technic Ribbed Hose, 71944 It's made of sections that make it bendable; 71944k01 and 71944k02.
But some of the sub-Parts might need some editing.  Let us start with these 2 parts that also need renumbering, 572c01 and 572c02

   
   

There are 5 sub-Parts that could be renumbered and use the k0X-suffix, but 2 of them (d and e) are not used in any parts.
Are they used and useful in LSynth? I don't know.  Steffen has a long lasting Hold vote on them.

Should we standardize them so that they are suitable for LSynth? How?
How should a Flex_section be made to be useful in LDCad?

Hey
I have a small problem - when I use, for example, the color reddish brown (70,p), there is a white edge line, is it possible to change it in the configuration so that it becomes black?

Many thanks in advance - dkd