WebGL renderer


WebGL renderer
#1
Hello! I'm playing with LDraw a lot lately, and i decided to implement something to display models with WebGL.
Here's the experimental results and some more information:

http://www.lugato.net/ldraw/page.html
new url: http://www.lugato.net/brigl/index.html

I think a WebGL renderer would be great to show off models on the web. No plugin, no downloads, etc.
It's very crude but it already show some models

Ideas and feedbacks are welcome Smile
Reply
Re: WebGL renderer
#2
Due to my low level grafik card I am unable to use WebGL at all. I fear there are many people out there with the same problem. But I am sure one day I am able to see your work Smile
Reply
Re: WebGL renderer
#40
On my Laptop I just needed to update to the latest driver Wink

Really great to see that working.

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 Smile


Attached Files
.mpd   8464 - Front End Loader.mpd (Size: 53.64 KB / Downloads: 0)
Reply
Re: WebGL renderer
#41
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 Smile

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 Smile

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 ?

Edit: maybe it's a strange color i can't parse
Reply
Re: WebGL renderer
#42
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.)
Reply
Re: WebGL renderer
#54
I just tested again with the same file, but unfortunately it still does not work Sad
If I can be of any help please let me know.
Reply
Re: WebGL renderer
#55
yeah i still havn't solved the bug.. i'll look into it asap Smile
Reply
Re: WebGL renderer
#59
ok i verified the problem. There's a line that breaks everything:

1 117313504 -125 -208 -400 0 0 1 0 1 0 -1 0 0 3941.DAT

The color number is clearly off and javascript chokes. Replacing with the following will work.

1 14 -125 -208 -400 0 0 1 0 1 0 -1 0 0 3941.DAT

Note that the other problem is still there. Also i noticed that the file use spaces in internal file names, i think brigl don't like that either.
I've attached the cleaned file. Here's how it render:

[Image: tTV6b.png]


Attached Files
.mpd   8464-cleaned.mpd (Size: 53.42 KB / Downloads: 2)
Reply
Re: WebGL renderer
#60
The colour number is not off, it's an custom one.

See also this recent thread:

http://forums.ldraw.org/showthread.php?t...60#pid7660
Reply
Re: WebGL renderer
#61
ohh thanks! that was the same model too.
i think i'll pass this one
Reply
Re: WebGL renderer
#62
Thanks for the update.

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 Smile
Reply
Re: WebGL renderer
#63
yes it currently support single space separators but nothing else (no double spaces etc) Smile it needs to be fixed
Reply
Re: WebGL renderer
#3
Looks rather nice for something "very crude" Wink
Reply
Re: WebGL renderer
#4
That is awesome.

Tim
Reply
Re: WebGL renderer
#5
AWESOME! AWESOME!

But I ask myself why you need a server-side piece of software to achieve that.
The LDRAW syntax is so simple that JavaScript _itself_ could parse it and produce the data for the WebGL render...

An implementation like that is exactly what I had in mind when writing this:
http://forums.ldraw.org/showthread.php?t...63#pid1963
Reply
Re: WebGL renderer
#6
Thank you Smile
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
Reply
Re: WebGL renderer
#7
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.
Reply
Re: WebGL renderer
#8
I disagree that parsing ldraw files is easy. It's actually quite annoying in many ways. Not a difficult problem, but with enough quirks to make it painful.

Tim
Reply
Re: WebGL renderer
#10
Yeah, there are some really weird stuff, such as the conditional lines, ccw vs cw faces, inversion of subpart, etc .. i spent quite a lot to get that right Tongue
Reply
Re: WebGL renderer
#9
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.
Reply
Re: WebGL renderer
#11
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 Smile
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
Reply
Re: WebGL renderer
#12
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.
Reply
Re: WebGL renderer
#13
Or store the parts pre-processed somewhere and read that. If you've got them on your own server you're not limited to LDraw File Format.

Tim
Reply
Re: WebGL renderer
#14
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 Smile

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

Here's a simple display:

http://www.lugato.net/ldraw/simple.html

And here's a page that lets you paste LDraw model in a textarea to load them:

http://www.lugato.net/ldraw/copypaste.html

And a page with multiple models in a gallery like fashion (caution: use lots of ram Tongue):

http://www.lugato.net/ldraw/multiple.html

Note that my server doesn't GZip.
So there's much room for improvements, for example optimizing part requests, 3d rendering (some better filtering and lighting), zooming, compression of parts, etc.

Let me know if something go wrong while you try it. note that there may be some missing parts on the server.
Reply
Re: WebGL renderer
#15
Nicola Wrote:http://www.lugato.net/ldraw/simple.html

"Something went wrong loading: 48\....dat"

and there a lots of these messages after loading the page. Afterwards it freezes saying "Initializing..."

w.
LEGO ergo sum
Reply
Re: WebGL renderer
#21
I have the same problem as Willy. Could be an issue with / vs. \ in pathes?
Reply
Re: WebGL renderer
#22
is most surely is. you're probably using firefox, right? chrome does slash substitution but firefox not.

it's fixed now, can you retry?
Reply
Re: WebGL renderer
#25
Crossed posts... but no, it's doesn't work better now Sad
Reply
Re: WebGL renderer
#27
Working now! Just loaded a MPD containing an unofficial. Jaw-dropping!

w.
LEGO ergo sum
Reply
Re: WebGL renderer
#28
Still nothing here. Could a cache issue be possible?
Reply
Re: WebGL renderer
#29
Philippe Hurbain Wrote:Still nothing here. Could a cache issue be possible?

Maybe yes, did you tried cleaning your browser cache?
Reply
Re: WebGL renderer
#30
No I didn't - and didn't need so! It now works fine with Seamonkey...
Really great work Wink
Reply
Re: WebGL renderer
#24
More details: Works fine with Chrome, but not with Seamonkey (a Firefox variant).
Otherwise, really great!
Reply
Re: WebGL renderer
#16
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!
Reply
Re: WebGL renderer
#17
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 Big Grin

© mousewheel:
I am missing the use of the mousewheel for zooming...

(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.
Reply
Re: WebGL renderer
#23
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 Smile

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 Big Grin

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 Smile 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 Smile

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 Smile Another quirk of LDraw is how it mixes CCW and CW faces and how it "inverts" subparts Smile
Reply
Re: WebGL renderer
#26
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.
That's what LDview does.
Reply
Re: WebGL renderer
#33
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 Smile
I know, I was asking just for the simple, normal edges.
Reply
Re: WebGL renderer
#36
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 Smile 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

see here for all links

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.

Let me know of any bug Smile
Reply
Re: WebGL renderer
#37
Wow.
Wow, wow!!!
Amazing!
Quote:- experimental step support
One thing missing (but then - it's experimental!): orientation/scale should be kept when changing step.
Reply
Re: WebGL renderer
#39
yes, I agree. when going a step forward or backward, the perspective that the user has established with the mouse
should not be modified.
Reply
Re: WebGL renderer
#38
Nicola Wrote:Let me know of any bug Smile

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
Reply
Re: WebGL renderer
#18
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!


Attached Files
.ldr   862ac02_with_cable.ldr (Size: 59.4 KB / Downloads: 1)
Reply
Re: WebGL renderer
#19
Code:
var flip = geometry._inverting ^ (det<0.0) ^ (!ccw); // kungfu

hahahaha, liked that
Reply
WebGL in Firefox (or other Mozilla browsers?)
#35
I was able to run this in Iron/Chrome, but not in Firefox.

Searching for the cause, I found this information:

http://www.sitepoint.com/firefox-enable-...hics-card/
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.)
Reply
Re: WebGL renderer
#20
NICE JOB!
Reply
Re: WebGL renderer
#31
This is working out all fine which leads us to the ultimate question:

How do we implement such a renderer into the forum or the CMS once it if fully featured?

w.
LEGO ergo sum
Reply
Re: WebGL renderer
#32
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.
Reply
Re: WebGL renderer
#34
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.
Reply
Re: WebGL renderer
#89
I still wonder if this is doable - Orion?

w.
LEGO ergo sum
Reply
Re: WebGL renderer
#90
+1

if BrickSet can do it,
then why shouldn't we be using it in the forums and the PT?
Reply
Re: WebGL renderer
#43
Hi, i've updated the library. See the results here:

http://www.lugato.net/brigl/index.html

News are:
- Better step support (not ideal yet)
- Better handling of non-BFC certified parts
- More optimized vertex merging
- Added smoothing of faces based on Conditional Lines (man if this was hard)
- Added specular light component
- Various fixings

I'm also setting up a public repository (with instructions and sources) so i can stop spamming here.
As always, feedbacks are welcome Smile
Reply
Re: WebGL renderer
#44
Even greater... Smoothing is definitely worth the headhache you got Wink
Quote:I'm also setting up a public repository (with instructions and sources) so i can stop spamming here.
That's not spamming! please keep us informed!
Reply
Re: WebGL renderer
#45
Nicola Wrote:- Added smoothing of faces based on Conditional Lines (man if this was hard)

I totally agree that is hard (having done it in LDView). Looking at your samples, though, it looks like you did a great job; the results look awesome.
Reply
Re: WebGL renderer
#46
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:

http://www.lugato.net/brigl/

The repository i set up is here:

https://bitbucket.org/msx80/brigl

That's all Smile
Reply
Re: WebGL renderer
#47
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).
Reply
Re: WebGL renderer
#48
lol i tested stuff for ages, i don't know how i missed that one.. It's correct now Smile
Reply
Re: WebGL renderer
#49
Quote:It's correct now Smile
Confirmed!
Reply
Re: WebGL renderer
#50
this is so ULTIMATELY cool...
Reply
Also trying LDraw in WebGL
#51
Very impressed with what you've got there.

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.
Reply
Re: Also trying LDraw in WebGL
#52
Much rougher than yours atm. But here is my WebGL LDraw project.
The parts list on my server is a cut down one, so most models won't work yet.
http://mr-bucket.co.uk/TestWebGL.aspx
Reply
Re: Also trying LDraw in WebGL
#56
Daniel B Wrote:Much rougher than yours atm. But here is my WebGL LDraw project.
The parts list on my server is a cut down one, so most models won't work yet.
http://mr-bucket.co.uk/TestWebGL.aspx

That's great Smile An online editing tool would be nice!
Reply
Re: WebGL renderer
#53
I would like to use this on my website. Can't wait!!
Reply
Re: WebGL renderer
#57
Thanks Smile Well if you want to use it you can do that already. All sources are up and installing should be straightforward but if you need help just ask. I'm already using it in a project of mine
Reply
Re: WebGL renderer
#58
I had also an eye on that, but for me it was not "straight forward" Sad so I pushed it away that day.
Maybe you can write some lines how to make it work. Smile
maybe I am tooooo stupid.
Reply
Re: WebGL renderer
#64
Yes, some instructions would be nice, as well as a zip file with everything we need in it.
Reply
Re: WebGL renderer
#65
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.
Reply
Re: WebGL renderer
#66
This can be fixed using an alternative filesystem or different formatting parameters for ext3/4
Reply
Re: WebGL renderer
#91
I have no control over the file system. I just rent space from a web hosting company.
Reply
Re: WebGL renderer
#67
For Fat32 see here for the limits: http://help.lockergnome.com/windows2/fil...50749.html
For NTFS see here for the limits: http://superuser.com/questions/446282/ma...l-vs-fat32

And some thoughts on ext3 here: http://serverfault.com/questions/129953/...ptable-per
Reply
Re: WebGL renderer
#68
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...
Reply
Re: WebGL renderer
#69
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.
Reply
Re: WebGL renderer
#70
Hey Nicola,

your Brigl renderer is really awesome. I gave it a try and it works great for my concerns.

I hope it is still ok for you if I use it on a webpage (e.g. http://www.digital-bricks.de/en/index.php?site=flp)?

Thanks for sharing.
Rolf
Reply
Re: WebGL renderer
#71
Of course it is, that's why i made it Smile
Reply
Re: WebGL renderer
#72
Question is: Is there a way to use it here on the forums in some ways? For example generating pics of models or parts people just submit as .ldr or .dat and a pic of the content is added to the post?

w.
LEGO ergo sum
Reply
Re: WebGL renderer
#73
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).

Here's a more detailed howto.

You can take a look at the simplest example here.
Rebrickable is also using brigl on their part detail page.
Reply
Re: WebGL renderer
#75
Hey Nicola,

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):

Code:
asyncReq: function(partName, callback)
{
  var purl = "../parts/"+partName;
  purl = purl.replace(/\\/gi,"/");
  this.asyncnum++;
  new Ajax.Request(purl, {
    method:'get',

    onSuccess: (function(transport) {
      var res = transport.responseText;
      this.asyncnum--;
      callback(res);
    }).bind(this),

    onFailure: (function() {
      purl = "../p/"+partName;
      new Ajax.Request(purl, {
        method:'get',
        
        onSuccess: (function(transport) {
          var res = transport.responseText;
          this.asyncnum--;
          callback(res);
        }).bind(this),
  
        onFailure: (function() {
          this.asyncnum--;
          alert( 'Something went wrong loading: '+purl);
        }).bind(this)
      });
    }).bind(this)
  });
},

Due to my missing knowledge of JavaSkript, I have no idea if my code causes deadlocks or
dead threads or ... whatever. But it seems to work with the standart folder structure: http://www.digital-bricks.de/en/index.ph...&part=3005

I would really like to see your Brigl renderer used at the parts tracker and / or in this forum.

Rolf
Reply
Re: WebGL renderer
#76
This is in the works. I just want to make sure it "fails gracefully" on unsupported browsers/hardware
Reply
Re: WebGL renderer
#77
YAY! hurray!
Reply
Re: WebGL renderer
#95
brigl does not seem to support the mpd file format...

is there any way to have it parse it properly?
Reply
Re: WebGL renderer
#74
WOW; that would be AWESOME...

EVEN the parts tracker could show the PARTS this way...

imagine a 3D object there, interacting with your mouse...
Reply
Re: WebGL renderer
#78
I'm having trouble implementing the viewer.
Everything seems to be working fine. The log messages are displaying but the viewer doesn't appear.

I think this might be a file path issue. I'm using:
Code:
var builder = new BRIGL.Builder("parts/",{dontUseSubfolders:true});

What should the library path I pass to the viewer be relative to? The html file containing the viewer code? Absolute for the webserver?
Reply
Re: WebGL renderer
#79
Hey Orion,

for the digital-bricks.de website, I use the following line:

Code:
var builder = new BRIGL.Builder("../parts/", {dontUseSubfolders:"true"});

I use the relative path from the html file containing the viewer code. When your parts folder and this file are in the same folder you may try "./parts/".

Rolf
Reply
Re: WebGL renderer
#80
Ok. It was a path and permissions problem with my local server. Hopefully I fixed it and can have this up soon on the forums.
Reply
Re: WebGL renderer
#81
Still getting a 403 forbidden error code even though I've set the parts directory to global read/write. Any ideas?
Reply
Re: WebGL renderer
#82
This is totally on my end and in no way related to the brigl software. I'l have to troubleshoot some more.
Reply
Re: WebGL renderer
#83
Ok, I've worked out the bugs. Now clean up the viewport code and implement fallback code.
Reply
Re: WebGL renderer
#84
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
Reply
Re: WebGL renderer
#85
I am still dreaming of seeing brigl being used for the parts display on the Parts Tracker
and of files posted here in the forum...
that'll just be *awesome*
Reply
Re: WebGL renderer
#86
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.
Reply
Re: WebGL renderer
#87
Big Grin
Reply
Re: WebGL renderer
#88
Hi everybody,

I have download all sources and parts, upload them on my server.
Implement the viewer, but nothing appear !!!!

http://www.brickmarket.fr/gui/webGL3D/web/simple2.html

I just try to see the part 3005.dat.

Model loaded successfully
Generating geometry
Loading 4-4disc.dat
Loading 4-4cyli.dat
Loading 4-4edge.dat
Loading stud.dat
Loading box5.dat
Loading ../parts/3005.dat
Creating ../parts/3005.dat...
Initializing...

Could you help me ?
Reply
Re: WebGL renderer
#92
Hey there Nicola,

Been playing around with Brigl and must say I love it.

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.
Reply
Re: WebGL renderer
#93
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?

Rolf
Reply
Re: WebGL renderer
#94
Hey Rolf, thanks for posting the reply Smile - where would I append the code to enable it? I am litterally |-----| << this close to getting it to work on my blog Smile
Reply
Re: WebGL renderer
#96
Rolf, I fixed the hardcoding:

asyncReq: function(partName, callback) {
var purl = this.partsUrl + partName;
purl = purl.replace(/\\/gi, "/");
this.asyncnum++;
new Ajax.Request(purl, {
method: 'get',
onSuccess: (function(transport) {
var res = transport.responseText;
this.asyncnum--;
callback(res);
}).bind(this),
onFailure: (function() {
purl = this.partsUrl + /p/ + partName;
new Ajax.Request(purl, {
method: 'get',
onSuccess: (function(transport) {
var res = transport.responseText;
this.asyncnum--;
callback(res);
}).bind(this),
onFailure: (function() {
this.asyncnum--;
alert('Something went wrong loading: ' + purl);
}).bind(this)
});
}).bind(this)
});
},
Reply
Re: WebGL renderer
#99
Nathanel Titane Wrote:Hey there Nicola,

Been playing around with Brigl and must say I love it.

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 Smile 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?

Let me know if you need more help Smile
Reply
Re: WebGL renderer
#97
Nicola, any way to add touch event listenenrs to brigl?
Reply
Re: WebGL renderer
#98
Well, my friends, here is what I've got so far: http://nathaneltitane.blogspot.ca/p/test_6.html
Reply
Re: WebGL renderer
Hello Nicola,

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:

https://github.com/HazenBabcock/brigl

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

best,
-Hazen
Reply
Re: WebGL renderer
Hazen Babcock Wrote:Hello Nicola,

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:

https://github.com/HazenBabcock/brigl

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.
Reply
Re: WebGL renderer
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.

best,
-Hazen
Reply
Re: WebGL renderer
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?
Reply
Re: WebGL renderer
Does it work on either of these sites?
http://www.lugato.net/brigl/index.html
http://hazenbabcock.github.io/brigl/index.html

Can you send me the file? I can try it to see if it works for me.

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.

-Hazen
Reply
Re: WebGL renderer
Yes, it works perfectly fine on those websites and yes, I know about the development tools. Wink
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.
Reply
Re: WebGL renderer
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?

-Hazen
Reply
Re: WebGL renderer
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).

Maybe you can include it in the HOWTO.txt?

Ah well, it's working now. Thanks a lot! Smile
Reply
Re: WebGL renderer
It is good to hear that it is working now.

Thank you for the suggestion, I added a note to HOWTO.txt and a warning message to BriglContainer.

-Hazen
Reply
Re: WebGL renderer
I'd like to include this in the omr website. However, I have 2 feature requests that would make it a little better for the omr site:
  • The LDraw files are saved with their 'OMR filename'. That means that sometimes, the loadByUrl receives a url like this:

    /media/LDraw_files/Pharaoh's%20Quest/30091/30091%20-%20Desert%20Rover.mpd

    It doesn't have any problems with the %20, but the ' (which is transformed into 'Wink seems to be a problem.
    That doesn't work. Is it possible to add support for those links?
  • It would be nice if Brigl would detect a large model (e.g. models with more than 1500 parts) and if it detects one, it doesn't load the model without the user's 'permission' (e.g. a button).

Those are 2 things I can think of at the moment to make it more suitable for the OMR.
Reply
Re: WebGL renderer
Does Brigl still require all parts in separated directories?
Reply
Re: WebGL renderer
No. You can also use 1 folder with all parts. Altough you do need to combine all p and parts folders of both official and unoffical in 1 huge folder.
Reply
Re: WebGL renderer
Or you can have a look at this variation: http://forums.ldraw.org/showthread.php?t...53#pid9953

Rolf
Reply
Re: WebGL renderer
That's still less than ideal to the point where I wouldn't really want to use it.
Reply
Re: WebGL renderer
Hmm, I need to follow this topic.
No further comments, but this is great.
I just copy/pasted a model and it looks very nice!
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: WebGL renderer
(2016-03-06, 18:33)Merlijn Wissink Wrote: I'd like to include this in the omr website. However, I have 2 feature requests that would make it a little better for the omr site:
  • The LDraw files are saved with their 'OMR filename'. That means that sometimes, the loadByUrl receives a url like this:

    /media/LDraw_files/Pharaoh's%20Quest/30091/30091%20-%20Desert%20Rover.mpd

    It doesn't have any problems with the %20, but the ' (which is transformed into ') seems to be a problem.
    That doesn't work. Is it possible to add support for those links?
  • It would be nice if Brigl would detect a large model (e.g. models with more than 1500 parts) and if it detects one, it doesn't load the model without the user's 'permission' (e.g. a button).

Those are 2 things I can think of at the moment to make it more suitable for the OMR.

1) How is this URL generated? I don't think brigl has any trouble with an un-escaped URL, as this works for me:

builder.loadModelByUrl("/media/Pharaoh's Quest/30091 - Desert Rover.mpd", ..)

As long as I actually have a file with that name in the correct location.


2) This might be better done with some sort of wrapper rather than brigl itself? The code that is generating these web-pages could perhaps insert a button for large models?

(2016-03-07, 10:39)Rolf Osterthun Wrote: Or you can have a look at this variation: http://forums.ldraw.org/showthread.php?t...53#pid9953

Rolf

This link appears to be broken.

Anyway maybe you'd be interested in forking the project and creating a pull request for this change?

-Hazen
Reply
RE: WebGL renderer
Could someone write a tutorial on getting this to work on one's own site? The brigl site does not have instructions. Thanks.
Reply
RE: WebGL renderer
(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.
Reply
RE: WebGL renderer
(2016-07-31, 8:23)Merlijn Wissink Wrote:
(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.
Reply
RE: WebGL renderer
It's this HOWTO.txt file I was referring to.
Reply
RE: WebGL renderer
Okay thanks. I did not realize it was on github.
Reply
RE: WebGL renderer
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.

[edit]

Here is my first model that I got working:

http://isometricland.net/lego/brigl/ldr_androbot.php

I tried enabling the "dontCenter" option because I want the script to use the model's coordinate system, but this placed the camera directly at the robot's feet. I could not zoom out any further.
Reply
RE: WebGL renderer
Feedback:

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.

http://isometricland.net/lego/brigl/ldr_...ehouse.php

Not sure why. The others work. Lack of memory?
Reply
« Next Oldest | Next Newest »



Forum Jump:


Users browsing this thread: 3 Guest(s)
Forum Jump:


Users browsing this thread: 3 Guest(s)