Michael Heidemann Wrote:But I run into an error by processing the attached file. I know it's still beta or alpha, but just at that point I am sure every feedback will help you

Uhm it looks like the problem is that there are two submodels referenced by a previous model. My parser assumes MPD contains models sorted by dependency, with the last one being indepentent, the previous one depending on the last and so on. This helps parsing a little, and since all mpd i tryed worked this way i assumed this was standard. Maybe i'm wrong

Saying that, i've tryed to move 8464 - Cylinders1.ldr and 8464 - Cylinders2.ldr to the bottom but it still doesn't work. No error reported but no model too.. Maybe is too big ?

Actually, the MPD spec requires that the very first file in the MPD be the main model, so it is guaranteed that all correctly formatted MPD files will have dependent models show up later in the file. (It could be that you meant all the other models in the file show up in order, but that's not required by the MPD spec.)

Regarding filenames with spaces I found no limitation in our specs that they are not allowed. Even more in the spec for OMR the delimiter for set number and set description is " - " (whitespace, dash, whitespace). So your parser *needs* to support whitespace in filenames.
I am sure you will find a solution

Thank you
Just to clarify, there are no server-side software, the "conversion" program runs offline and produces a javascript file with all the model vertices etc. You can see it here. The js is included in the html and then everything run off the client.

The reason i decided not to do even the parsing in javascript is becouse, while the ldraw format is easy to read, it is quite tricky to work with. And also, if you implement the parsing in javascript, you must have some way to load part files ad needed, and that mean having a web server with all the library loaded (i don't know, maybe one exists?). Given that, probably it could work!

Now i want to try to integrate the program with a better 3d library such as Three.js

Hmm, well, such webserver exists: ldraw.org ;-),
however, it probably would be more practical to keep a .zip with the latest parts update on YOUR server,
to avoid all the traffic to ldraw.org.
I really would suggest to implement parsing etc. in JavaScript, full on client side,
it is very easy to do, and as long as you have a .zip available with the latest parts update,
you can display any model a user likes.
You can download the .zip do the browser cache of the client.
And put an input control onto a page, so a user can browse for a model (*.ldr or *.mpd file)
to display OR specify the URL to it.
Then you would parse it by JavaScript, use the .zip library I just mentioned, and - voila - send it to WebGL.

Given that the current complete.zip is 19.1MB, I'm not sure that's the best way to work things. Every time it gets out of the browser cache, it would have to be reloaded in its entirety, plus any casual user that just looks at one file would have to wait for the 19.1MB download before anything would happen.

Having said that, while ldraw.org does in fact host all of the official (and unofficial) part files on its web server in a fashion that would allow automatic download, ldraw.org is also fairly slow, and getting the parts from there would probably be quite slow. Also, the last time I checked (which was admittedly years ago when implementing automatic download in LDView), gzip compression was wasn't enabled on ldraw.org, so downloading parts actually transfers all the bytes, even though part files compress extremely well, and gzip compression is standard in http 1.1.

yeah, working with the whole package is not ok. my latest idea is this: upload all parts as single file in some server where you can query single parts. Then in javascript i scan an ldr/mpd and for any reference to a subpart, i query the server to obtain it, and use all the parts to build the full geometry.
This would allow displaying of arbitrary models (ie embeddable in html, from user textarea, etc) without any server side work, with hopefully minimal bandwidth usage. I've tested that my Viper model uses about 80 parts for about 300kB total, which can be compressed to about 30kB with gzip, quite good. With this performances is more easily to overload the video card than to use too much bandwidth
The only problem is that it would generate 80 asynchronous request to the server, which can be quite a lot. But parts file are cacheable so that should help.
I'll try asap

nice idea. just some more thoughts to share:
you could in fact put all the parts to the server,
then have the client send a "list of needed parts" to it.
the server could put all the needed files into a *.mpd on the fly (which is trivial),
and then that result could get send gzip compressed to the client.

Here the new version!
Now it's all javascript. It asynchronously fetch all part data from a server, build the model and display it. No server logic. The parts on the server are unprocessed, they're just redistribuited in different subfolder as my server was complaining about 7000+ files on a single dir

The main javascript object mantain a cache of already downloaded parts, so if you show multiple models the fetches are limited.

I bow to you.
Seeing the loading progress text messages rush through,
and then seeing the model so beautifully is just amazing.
Great compliments! I am truly amazed! The beauty of this solution is
that it is NOT tied to either iOS or Android, but still can be seen on mobile devices, as long as the browser sports WebGL.
This embodies the MAIN principle of the Internet, offering contents INDEPENDENTLY of OS or browser brand.
Would we have to implement an Android App, an iOS App, an XYZ App separately, this would multiply the needed
effort. THIS way, all is bundled in ONE. YES, it's JavaScript, and JavaScript is not (to my eyes) the most beautiful
of all programming languages, but browsers nowadays are HIGHLY optimized for it, and you can always put something
ELSE to work together with it. However, for a browser, it's the most natural choice, being - in my eyes - MUCH better than
Flash or Silverlight, which again would be vendor-specific.
Good decision, and an impressive prototype. Kudos!

the improvements which I spontaneously like to collect here, jumping to my eye or mind, are

(a) rotation center:
The center of rotation currently seems to be hardcoded 0/0/0.
I would better like to have it at the model's center, like in LDView.
Using the mouse currently in your web app feels so different than LDView,
that it confuses me. I would love to see a big similarity in mouse handling between the 2 tools.

(b) incremental parts display:
perhaps it is very easy to do, and you could show the model already while it is loading.
the user can watch the downloaded parts appear in the model.
I think it could be quite cheap to do, because you already know all the matrices etc, just the "real" part data is missing.
Thus, you could already build up the necessary data structures, and skip them on rendering, while the model is not fully loaded.
I think this would be an evern more "incremental" load than displaying the progress status message

(d) default color 16:
Nicola, you seem to currently use 0/0/0 always for default color 16.
I would prefer if you would use the color specified explicitly in LDConfig.ldr (some "medium" default grey).
To you already use that file? You can always get the most recent version also from the ldraw.org site.

(e) edges:
you currently are not rendering edges at all.
I would like to have a checkbox or button for toggling that on and off.
It should be nearly trivial to add the drawing of them to your existing implementation.

Steffen Wrote:the improvements which I spontaneously like to collect here, jumping to my eye or mind, are

(a) rotation center:
The center of rotation currently seems to be hardcoded 0/0/0.
I would better like to have it at the model's center, like in LDView.
Using the mouse currently in your web app feels so different than LDView,
that it confuses me. I would love to see a big similarity in mouse handling between the 2 tools.

Yes that's hardcoded now. I don't know if ldview calculates the center automatically or uses some metadata in the file. i have to make some tests.
About the mouse, i just thrown in a working system, it surely can be improved, and it needs zooming with the wheel

Steffen Wrote:(b) incremental parts display:
perhaps it is very easy to do, and you could show the model already while it is loading.
the user can watch the downloaded parts appear in the model.
I think it could be quite cheap to do, because you already know all the matrices etc, just the "real" part data is missing.
Thus, you could already build up the necessary data structures, and skip them on rendering, while the model is not fully loaded.
I think this would be an evern more "incremental" load than displaying the progress status message

Yeah i considered it too.. Seeing the model progressively being built would be awesome. It might not be very hard but needs some modifications on the program.

Steffen Wrote:(d) default color 16:
Nicola, you seem to currently use 0/0/0 always for default color 16.
I would prefer if you would use the color specified explicitly in LDConfig.ldr (some "medium" default grey).
To you already use that file? You can always get the most recent version also from the ldraw.org site.

I've yet to understand completely how color works, but i got that 16 is actually the "current color", and i correcly substitute it with what "parent lines" says, it's not hardcoded to 0. What i miss is the whole "complementary" colors and code 24.

Steffen Wrote:(e) edges:
you currently are not rendering edges at all.
I would like to have a checkbox or button for toggling that on and off.
It should be nearly trivial to add the drawing of them to your existing implementation.

Normal edges would be trivial, conditional edges will be not They're one of the most puzzling quirks of LDraw file model. Basically you cannot just send them to OpenGL as a bunch of vectors, you have to manually test one by one and decide if you should draw them with a quite complex algorithm. It looks like some kind of hardcoded, precalculated "toon shading" like algorithm?
What i'd like to do is to use them to see if faces should be smooth or flat (basically what they tell is if the two faces should be "curved" or separated) so that i can render curved part nicely, but that require some work.

Steffen Wrote:Nicola, I am again falling of my chair, impressed.
I just tested the attached file, which uses an LSYNTH synthesized cable,
plus unofficial parts, it loaded quickly and smooth, and looked beautiful!

That's not my merit, LSynth generates standard faces, i didn't do anything special for it

Steffen Wrote:

Code:

var flip = geometry._inverting ^ (det<0.0) ^ (!ccw); // kungfu

hahahaha, liked that

Lol, that code required quite a lot of trial and error Another quirk of LDraw is how it mixes CCW and CW faces and how it "inverts" subparts

Quote:I've yet to understand completely how color works, but i got that 16 is actually the "current color", and i correcly substitute it with what "parent lines" says, it's not hardcoded to 0. What i miss is the whole "complementary" colors and code 24

Indeed, color 16 "inherits" color of parent part. Problem is if there is no parent (eg. if you paste the code of a LDraw part in copypaste.html). This requires the definition of a "default color" to be used in that case.
Color 24 does the same, but for edge lines.

Quote: It looks like some kind of hardcoded, precalculated "toon shading" like algorithm?

I think it can be described this way...

Quote:What i'd like to do is to use them to see if faces should be smooth or flat (basically what they tell is if the two faces should be "curved" or separated) so that i can render curved part nicely, but that require some work.

Nicola Wrote:I've yet to understand completely how color works, but i got that 16 is actually the "current color",
and i correcly substitute >it with what "parent lines" says, it's not hardcoded to 0. What i miss is the whole "complementary" colors and code 24.

As Philo already answered, colors 16 and 24 are for "use parent color".
I just asked to correct the implementation of "what to do when there's no parent".
For example, I put some unofficial part from the parts tracker into your tool.
Then it gets all black, because you map color 16 to "parent color", and when there is no parent,
then use 0/0/0. My only, very simple, request was, as color 16 for this purpose has a R/G/B value
set in ldconfig.ldr, that you use _that_ color from there when there's no parent, instead of 0/0/0

Nicola Wrote:Normal edges would be trivial, conditional edges will be not

Steffen Wrote:as color 16 for this purpose has a R/G/B value
set in ldconfig.ldr, that you use _that_ color from there when there's no parent, instead of 0/0/0

Oh ok, didn't noticed this Implemented!

I've uploaded the new version, it includes:
- zooming and panning with mouse wheel
- mesh centering as LDview (and vertices merging for some performaces)
- very basic line handling
- experimental step support

line rendering is very limited becouse: 1) Three.js doesn't support different materials for same line geometry, so only black edges for now, and 2) line width is fixed to one pixel becouse the parameter is ignored (see here, looks like a webgl gap). In linux it should look better.

I think that the computation of the part center for rotation is not correct.
The topright red shuttle on page http://www.lugato.net/ldraw/multiple.html
does not rotate about its center. It rotates around "some other point".
EDIT: probably I am wrong here

Quote:"Your graphics card may be WebGL-compatible, but it’ll be blocked in Firefox if the driver version is 0.0.0.1 behind the approved list."

I applied the 3 changes mentioned there:
- To enable WebGL, set webgl.force-enabled to true
- To enable Layers Acceleration, set layers.acceleration.force-enabled to true
- To enable Direct2D in Windows Vista/7, set gfx.direct2d.force-enabled to true

, and voila, I also had WebGL in Firefox without problems.

Maybe it's the same for SeaMonkey.

(My graphics card is just a normal ATI Radeon HD 4600, which bought because it is passively cooled and thus silent.)

Well it's just importing the .js files and glueing some html and php for the forum.
The problem is making the parts avaiable on the server. They must be on the same server since they're fetched by ajax, or in a server that implement the Access-Control-Allow-Origin directive.

maybe we CAN allow to host the parts on the ldraw.org server,
BUT only activate your renderer for logged-in forum participants.
this way we can limit bandwidth, as we're not publicly offering the parts download to everybody,
and at the same time get the nice feature of 3D viewing arbitrary LDRAW files in realtime in the forums.

Hello, i've released a new version (version 4). This release add support for colored lines and a simple form of animations. I've added animations becouse i'd like to showcase moving parts of a model. It is based on code from TWEEN.js
You can find all here as usual:

The animations are really cute, especially the bounce at the end!
But "lines" example does no longer work here (hangs up at "generating geometry") (browser=Seamonkey 2.14.1, tell me if you need other details on my machine).

Recently thought i'd give WebGL a go my self. Mainly to replace the ancient LDraw cad software i made about 8 years ago: http://news.lugnet.com/cad/?n=11299 It's still available from that link if your interested.

Looks like your about two months ahead of me in dev. I have models loading and showing with nice normal's etc but it's all server side gen. Will let you know when i get mine up on a server.

Michael Horvath Wrote:Yes, some instructions would be nice, as well as a zip file with everything we need in it.

Ok, i'll write something. The hardest part is preparing the part library: pieces must be spread in different folders becouse servers tipically don't like 7000+ files in a single folder (btw this is something LDraw could consider too, that is not a good thing in general).
I'll write a little utility to do that.

i think this is something we should leave to the underlying filesystem:
from the perspective of the ldraw library, "parts" are in a, or better, in one "folder".
if this number of files is big and the filesystem internally wants to spread this, it can do.
outside, to the user, it should still be a single folder.
i do not want to search multiple folders for parts, and i especially don't want to do this different on different os' es...

While I'm not advocating splitting things up, it's definitely not up to the file system. The whole stated problem is that some file systems have problems when there are a large number of files in one directory. To be honest, I don't think the 6000+ files we have now is causing problems, but the file system can't internally spread them out, because that would redefine the meaning of a directory.

As for searching, do you do your searches against the actual files on the disk, or using tools based on LDraw? Any change to the folder structure would require updating all tools to support the change, which is why I don't think it will ever (or even should ever) happen. But since the tools would have to be updated anyway, a change in the underlying structure wouldn't change the user experience for people using the tools.

Yes, that shouldn't be hard. What you need to run it is loading the part library to some folder on the same origin as the page running it. I think Ldraw should already have it avaiable. The rest is standard javascript fiddling (include JS files, add some snippet of code, etc).

indeed, the LDraw site should have the complete library online (can somebody confirm that?).
I think the biggest challange is, that your renderer needs the complete library in a special
folder structure (one folder or your suggested subfolder structure).

I have almost no skills in JavaScript, but I had a closer look into your code, tried some
changes and used copy and past to generate the following code snippet (the paths are
hardcoded):

Orion Pobursky Wrote:Ok, I've worked out the bugs. Now clean up the viewport code and implement fallback code.

Hello there! Sorry, for some reasons i didn't received notifications and missed these new posts!
Let me know if you still need help with it. I'm planning to resume working on brigl soon and finally get the smoothing right and upgrading to the last version of Three.js

As usually happens when I'm near in completion of a project, real life got in the way. Hopefully I'll have some free time during the holidays to finish up the half a dozen little LDraw items I've been working on.

Nathanel Titane Wrote:Is there any way to revise or enable LDraw's standard parts directory listing instead of the parsing your JS proposes or the no subdir option (which forces everything into a single directory)?

Hey Nathanel,

it is some time ago now, but I once wrote this post. I think this is exactly what you are looking for?

Is there any way to revise or enable LDraw's standard parts directory listing instead of the parsing your JS proposes or the no subdir option (which forces everything into a single directory)?

Thank you.

Thanks the nosubdir option actually use the standard part directory listing, it is not that it require a single flat directory. Just use the option and plug your library as is, it should work.

Nathanel Titane Wrote:Nicola, any way to add touch event listenenrs to brigl?

Actually that is Threejs stuff. Brigl basically create a Threejs object, and then you can do whatever you want with it. I included the BriglContainer code that will create a very basic Threejs scene, but that's just for convenience.
Brigl already support mouse event, so i guess you need touch events such as from tablets or smartphones?

I've been hacking on this a bit as I was interested in something that would work on a tablet. I've added touch event handling (one finger to rotate, two to zoom / translate). I've also updated it to use three.js r74, tried to improve the centering and some other minor changes. If you are interested, my work is here:

I've been hacking on this a bit as I was interested in something that would work on a tablet. I've added touch event handling (one finger to rotate, two to zoom / translate). I've also updated it to use three.js r74, tried to improve the centering and some other minor changes. If you are interested, my work is here:

Is your brigl project on bitbucket still active? Can I send you a patch with these changes?

best,
-Hazen

Hi, very interesting, expecially the update of three.js. Have you adjusted the smoothing algorithm too? I remember that newer version of Three.js didn't have Quads anymore, and that broke my smoothing algorithm.

I'm not developing brigl anymore, but if i have the time i can try to merge your stuff.

Yes I did adjust the smoothing algorithm for the lack of quads. It is a little more complicated but it still (seems) to work..
My e-mail address is on my github page if you want to contact me directly.

I've tried using your new version on the OMR website and I'm still having the same problem as before your updated version: the log shows it's loading all parts (which I indeed see being downloaded in the browser), then the log shows "Model loaded successfully", but there's just nothing. No model, no error. Just that message.

Mind you: this is on my localhost and not on the 'real' omr server of course, but still... Everything seems to be working, except the actual webgl viewer. Am I just being overlooking something completely obvious?

Another thing that can be very useful (and maybe you are already aware of?) is that many browsers have "Developer Tools", which you can use to follow exactly what is going on. Most browsers will silently ignore javascript errors, which is fine for general use but can make it very hard to figure out what the issue is when you have a problem like yours. With the developer tools running you can now see any error messages, the console log, etc.

Yes, it works perfectly fine on those websites and yes, I know about the development tools.
That's the annoying thing; there are no errors in there...

Here's an example generated webpage (please save the file, I've uploaded it temporarily). Note that I've been moving the javascript files a bit and tried different versions, so that might be a bit messy. It still didn't work though.

I looked at this doc and my guess is that maybe it is a resizing issue. What is the initial size of the model_container div element? BRIGL won't resize the element, it will just draw it at whatever the current size is. Also, BRIGL doesn't handle resize events so the element has to already have the correct final size before rendering.

Is there a publicly accessible version somewhere that I could try and load in my browser?

Oh my god, you're right! I completely missed the fact that the div element needs to be set at a certain size manually. I was expecting Brigl to... just put the viewer in there. Well, not really expectingin, I didn't even think about either way. Actually, now I think of it, it's quite logical that it doesn't set its own size (I mean, it doesn't know what size it should be).

(2016-07-28, 10:20)Michael Horvath Wrote: Could someone write a tutorial on getting this to work on one's own site? The brigl site does not have instructions. Thanks.

I'm on vacation now so I am not at my good old desktop (and internet) to give a full explanation, but I believe the included readme explains (although relatively basic) how to use it. I believe it boils down to adding links to all the necesary javascript files and placing the LDra library somewhere on your webserver.

(2016-07-28, 10:20)Michael Horvath Wrote: Could someone write a tutorial on getting this to work on one's own site? The brigl site does not have instructions. Thanks.

I'm on vacation now so I am not at my good old desktop (and internet) to give a full explanation, but I believe the included readme explains (although relatively basic) how to use it. I believe it boils down to adding links to all the necesary javascript files and placing the LDra library somewhere on your webserver.

Where is the readme? I can't even find a download link on the Brigl site.

Does anyone know how to write a Windows batch file that sorts the parts library into sub-folders based on the first letter in the file name? The docs say that this should be done for performance reasons. Thanks.

[edit]

Never mind. I was able to move everything manually.

It is weird that your models need to go in the parts directory. I'd rather put them in a "models" directory next to "parts". Could this be changed in the future? Thanks.

1. One problem I noticed is that the viewer doesn't detect when the mouse leaves the display window. As a result, if you are holding a mouse button down when the cursor goes off screen, the viewer still thinks it is pressed when returning to the screen, even though you are likely to have released the button by then.
2. It would be nice to change the background color. I use a gray color normally in LDView.
3. How should we advertise for Brigl? Just link to the github page?
4. I would like to turn studs off to speed up rendering. Overall, performance is not as great as LDView.
5. Large models take a while to load. A better indication of loading using a GIF animation would be good.
6. Moving the scene using the middle mouse button is slow. You have to do it over and over again to make progress.
7. I added a border "border:3px double #888;" to the container, but the display overlaps this border to the bottom and right.

[edit]

This model crashes Chrome for some reason, and results in a black screen in IE.

If you are using the Github version of Brigl and you'd like some help, or you've found a problem, please open an issue on the Github project page. For reasons unclear to me, even though I think I'm subscribed to this thread I never get any e-mail notices about new posts.

(2018-02-19, 22:59)Hazen Babcock Wrote: If you are using the Github version of Brigl and you'd like some help, or you've found a problem, please open an issue on the Github project page. For reasons unclear to me, even though I think I'm subscribed to this thread I never get any e-mail notices about new posts.

(2018-02-19, 22:59)Hazen Babcock Wrote: If you are using the Github version of Brigl and you'd like some help, or you've found a problem, please open an issue on the Github project page. For reasons unclear to me, even though I think I'm subscribed to this thread I never get any e-mail notices about new posts.

There seem to be two problems here. The first is that this model requires two files 'm6666.ldr' and 'm6643.ldr' which are not found on this server. The missing file problem then triggers a call to an error callback function which has a bug, causing an exception and stopping the model loading process. I think the bug is fixed in the current version of BRIGL, but there is not much I can do about the missing files.

(2018-02-19, 22:59)Hazen Babcock Wrote: If you are using the Github version of Brigl and you'd like some help, or you've found a problem, please open an issue on the Github project page. For reasons unclear to me, even though I think I'm subscribed to this thread I never get any e-mail notices about new posts.

To me it looks like your library have issues.
I see two broken heads that I know have been reworked and corrected. They used an old obsolete subfile, and wasn't correctly bfc'd. They are corrected, but right now I don't know their status, official or unofficial.

(2019-06-28, 15:32)Magnus Forsberg Wrote: To me it looks like your library have issues.
I see two broken heads that I know have been reworked and corrected. They used an old obsolete subfile, and wasn't correctly bfc'd. They are corrected, but right now I don't know their status, official or unofficial.

(2019-06-28, 15:32)Magnus Forsberg Wrote: To me it looks like your library have issues.
I see two broken heads that I know have been reworked and corrected. They used an old obsolete subfile, and wasn't correctly bfc'd. They are corrected, but right now I don't know their status, official or unofficial.

I updated my parts library to the one released a few days ago, but the problem persists. I wonder why the recently "fixed" versions weren't pushed to the official release.

The OMR uses Brigl to display models and uses the official, always up to date, library on the LDraw server. If there's a model currently in the OMR that uses the parts in question then you can use it to see if the problem recurs there.

(2019-06-28, 19:02)Orion Pobursky Wrote: The OMR uses Brigl to display models and uses the official, always up to date, library on the LDraw server. If there's a model currently in the OMR that uses the parts in question then you can use it to see if the problem recurs there.

There is a note on the OMR Brigl page that some models might cause Brigl to crash. Do you happen to remember which ones in particular are problematic?

(2019-06-29, 16:17)Orion Pobursky Wrote: I think it's less of a model problem and more of a problem with model size and horsepower of the rendering machine. Example: 10030 crashes the tab on my iPhone but loads perfectly fine on my desktop.

Maybe there is some way for Brigl to be more aware of the limitations of the browser that it is operating in. I'll look into this.

(2019-06-29, 16:17)Orion Pobursky Wrote: I think it's less of a model problem and more of a problem with model size and horsepower of the rendering machine. Example: 10030 crashes the tab on my iPhone but loads perfectly fine on my desktop.

I'd suggest using the "dontSmooth:true" option for the larger models. For example I tried to render 101341-1 (Y-wing Attack Starfighter) and after spending several minutes working on smoothing my browser timed out.

This model may take several minutes to fully load. It may seem as if the loading has become "stuck" and has stopped advancing. (This is my #1 major annoyance with brigl.) Just be patient and let the browser tab alone for a while.

This model may take several minutes to fully load. It may seem as if the loading has become "stuck" and has stopped advancing. (This is my #1 major annoyance with brigl.) Just be patient and let the browser tab alone for a while.

(2019-06-29, 16:36)Lasse Deleuran Wrote: It seems to be mostly caused by the latency between discovering and fetching parts. By optimizing this process it should become much quicker to load. I have uploaded it here on a page where the server pre-fetches parts you need and it loads much quicker - click "View 3D" to load the 3D model (and please tell me if you want me to delete the entry again - it is just uploaded as a demo)

By the way. This model is a wonderful test model. The use of "0 Name:" lines and naming with ".dat" is completely unexpected, so I will have to change my algorithm to properly detect this use case.

Interesting. I have some (outdated I'm sure) JavaScript experience, but none with AJAX or WebGL.

I'm not sure "0 Name" is an official LDraw comment type. I think MLCad did add it to the model, however. Also, the ".dat" extension is there because this model is nearly 20 years old. (It is also outdated, as am I.)

(2019-06-29, 16:36)Lasse Deleuran Wrote: It seems to be mostly caused by the latency between discovering and fetching parts. By optimizing this process it should become much quicker to load. I have uploaded it here on a page where the server pre-fetches parts you need and it loads much quicker - click "View 3D" to load the 3D model (and please tell me if you want me to delete the entry again - it is just uploaded as a demo)

They do, but files are fetched asynchroneously, so opening the sample files in your browser might not work out of the box due to default security settings. To get around this you can either host the files on a local server or disable the browser checks. As an example, Chrome can be started with the following parameters in order to disable these security settings:

(2019-07-18, 15:02)caesar Wrote: I just wanted to share this other online 3D webGL LDraw viewer that also uses bi.js: it adds the possibility to change the background and export the image as png: https://beta.makerbrane.com/tools/ldraw-viewer/