LDraw part 118091p looks fine in Part Designer but imports into Studio with extra geo

[Rodsal]

Hey everyone, I'm having a weird issue importing a custom part from the LDraw library into BrickLink Studio and I can't figure out what's going wrong.

The part is 118091p. When I open it in Part Designer it looks completely fine clean geometry, correct shape, everything as expected.

But the moment I open it or export it into Studio 2.0, it shows up with a bunch of extra pieces/geometry that don't belong there, like it's rendering additional parts that shouldn't be visible.

I'll attach screenshots showing the difference between how it looks in Part Designer vs Studio so you can see exactly what I mean.

Has anyone run into this before? Is this a known issue with how Studio handles certain LDraw file types? Could it be related to how the part references subfiles or primitives? Any help would be appreciated!

One more weird thing worth mentioning: if I zoom out, the extra geometry completely disappears and the part looks perfectly fine. But as soon as I zoom back in, the extra geometry shows up again. It feels like some kind of LOD (Level of Detail) rendering bug, but I'm not sure. Has anyone seen this behavior before?

Part Desginer



Studio


And weird thing with studio - zoom out



After more testing, it seems like the issue is with a specific subpart, not the whole 118091p file. That subpart renders fine and correctly in LeoCAD, Part Designer, and other viewers, but when the overall part is loaded into Studio, it seems like Studio is misidentifying that subpart as a different one entirely and rendering that other part's geometry instead. Zooming in and out actually shows the swap happening in real time  it's not just extra geometry appearing/disappearing, it genuinely looks like Studio is resolving the subpart reference to the wrong file at close zoom and falling back to the correct one at a distance. Feels like it could be a naming collision or a caching/LOD-resolution bug specific to Studio's part lookup, but wanted to see if anyone has run into this exact behavior before.

[Sylvain Sauvage]

Hi,

This is a general answer, I didn’t check that exact part and its components.

When you import a file in PartDesigner, it’ll first look for subfiles/subparts in the same folder (or a subfolder named ‘s’ when the files need to be in such a subfolder).
Then, when you export toward Studio, PD checks that the files that are needed are already known to Studio.  If not, they are inlined in the exported .dat.  Otherwise, it assumes they are the same files and it’s Studio’s stock files that will be used.

So, if you downloaded and extracted the Zip from the tracker, PD loaded the ‘local’ files… but if some of these files/subparts are already in Studio and they are older and different there, then you get surprises once in Studio.

One solution is to rename the local files and edit the main/calling file(s) accordingly to force PD to use these in the export.

[Philippe Hurbain]

The main problem is indeed that Studio LDraw library is NEVER properly updated. I have a parts pack for Studio including all the missing Cs&ai parts here: 
https://philohome.com/studio/packs.htm

[Orion Pobursky]

I'll add that if the state of Studio's library frustrates you, I suggest posting on their forums to either keep up with our releases or make it easier for users to update Studio's library with the official library.

[N. W. Perry]

I'll add that if the state of Studio's library frustrates you, I suggest posting on their forums to either keep up with our releases or make it easier for users to update Studio's library with the official library.

Indeed, it's to the point where I have to create separate versions of models to use them in Studio.

And since the only feature of Studio I really use is the Eyesight renderer, the best outcome would be if that rendering interface could be added as a module to, say, LDView.

[Orion Pobursky]

Indeed, it's to the point where I have to create separate versions of models to use them in Studio.

And since the only feature of Studio I really use is the Eyesight renderer, the best outcome would be if that rendering interface could be added as a module to, say, LDView.

Eyesight has been made open source (finally) so maybe someone with better coding skill than me can make a standalone.

[Sylvain Sauvage]

Eyesight has been made open source (finally) so maybe someone with better coding skill than me can make a standalone.

Not really.
Eyesight is a modified Blender 2.79/2.80.  It’s not a clean release version of Blender that was then modified, it’s one intermediary version of Blender that was modified, then updated to a new work version of Blender and modified again (and maybe even that but several times).
There’s much less work to redevelop something from Blender than to try to adapt Eyesight.
Plus, Blender 2.80 is from 2018, that’s an eternity of enhancements since.
Worse, Eyesight uses the Collada format, which is deprecated because unmaintened for years.
Double worse, the Collada format in Eyesight/Studio has been modified (without any documentation).
TL;DR: it’s a nightmare.

(Note that if it took so long for Eyesight to be open-sourced, it’s because it did not belong to BrickLink.  It had been subcontracted and it took BL some time to eventually buy all the rights.  And they made it open source because they don’t have the resources to do more than add or correct colours….)

[Orion Pobursky]

Not really.
Eyesight is a modified Blender 2.79/2.80.  It’s not a clean release version of Blender that was then modified, it’s one intermediary version of Blender that was modified, then updated to a new work version of Blender and modified again (and maybe even that but several times).
There’s much less work to redevelop something from Blender than to try to adapt Eyesight.
Plus, Blender 2.80 is from 2018, that’s an eternity of enhancements since.
Worse, Eyesight uses the Collada format, which is deprecated because unmaintened for years.
Double worse, the Collada format in Eyesight/Studio has been modified (without any documentation).
TL;DR: it’s a nightmare.

(Note that if it took so long for Eyesight to be open-sourced, it’s because it did not belong to BrickLink.  It had been subcontracted and it took BL some time to eventually buy all the rights.  And they made it open source because they don’t have the resources to do more than add or correct colours….

As I suspected, it would be better to just develop for Cycles directly.  See my other thread:
https://forums.ldraw.org/thread-29616.html

[Rodsal]

El principal problema es que la biblioteca LDraw de Studio NUNCA se actualiza correctamente. Tengo un paquete de piezas para Studio que incluye todas las piezas faltantes de CS&AI aquí: 
https://philohome.com/studio/packs.htm

No tienes idea de lo mucho que me ha ayudado este recurso. ¡Muchísimas gracias, de verdad!

[N. W. Perry]

Eyesight has been made open source (finally) so maybe someone with better coding skill than me can make a standalone.

Ooh, that's good news, I hadn't heard about that! Obviously Blender is open source, and LDraw-to-Blender conversion exists already, but the simplified, standalone UI used by Eyesight is very convenient (if a little lacking in documentation).

[Sylvain Sauvage]

The main problem is indeed that Studio LDraw library is NEVER properly updated.

It’s because Studio is not an LDraw application, it’s an application that uses LDraw (= the format, the 3D models of the Library, but not the Library).

Also, Cheenzo does what he can to update the 3D models but updating the whole Library is not how they want to do it 🤷‍♂️