ladybug-tools / bsdf-viewer Goto Github PK

I need some help for this to:

1. Understand the TT XML file structure - Greg has shared some code and documents for this and I have Andy's source code.

2. Support hemispherical projection for better visualization.

Documentation: https://developer.mozilla.org/en-US/docs/WebAssembly/C_to_wasm

From Greg's email to @andyrew:

Hi Andy,

Your required header file list should just be the first 9 you listed:

hilbert.h
fvect.h
ccolor.h
bsdf_t.h
bsdf_m.h
bsdf.h
platform.h
rtio.h
ezxml.h

Plus additional ones needed by the routines added below:

copyright.h
random.h

The rest should have older access dates than your compile. And yes, you do need to include all the bsdf*.c files, along with a few other support routines. Here's the list of required C modules:

bsdf.c
bsdf_m.c
bsdf_t.c
ccolor.c
disk2square.c
ezxml.c
fvect.c
hilbert.c
words.c

I hope I'm not forgetting anything. I know it's a lot, but still much less than the entire Radiance common library. A good test that you got everything is to compile these modules together to create testBSDF:

cc -o testBSDF testBSDF.c bsdf*.c fvect.c ccolor.c ezxml.c hilbert.c disk2square.c words.c -lm

Seems to work when I run it, and then "ls -ltu *.h" gives a complete list.

It is currently like a page designed in 1992 mixed with some interactive graphics. Needs a full re-design. We can use Ladybug Tools style.

This repository is imported from a gist and needs some extra work to be useful.

• put files in separate folders
• add license. I wanted to set it to MIT but because of the license of the code that I'm using for legend we must go with GPL v3.
• update readme - add a nice image, add credits and short description of what this BSDF viewer is

This is related to #3 but I thought I should start a new issue for this specific topic.

I did re-wrote @andyrew's implementation for drawing incident patches last night. The way the script works is that it draws the patches as line segments and circles. It works but it has a number of limitation - specially when it is used for outgoing hemisphere:

• lack of data binding: since every patch is drawn as unconnected segments there is no data-binding. For the incident hemisphere it will be fine as we can use the mouse cursor position to calculate theta and phi but with data-binding it will be much more elegant. It will also make interaction between two charts much easier.

• intensive boolean union process: another result of this approach is inability to use inbuilt boolean union methods for merging the patches with the same value for outgoing hemisphere. Right now Andy tries to find all the neighboring patches with the same value and draw the boundary line for them. It works but it would be much nicer to just use clipper.js or other available options: http://bl.ocks.org/nitaku/8751669/d2c51d092ae45d42037dfcd611aa312d359abcfd

I think we should implement this projection as a D3 Projection (https://github.com/d3/d3-geo/blob/master/README.md#projections) and then just use the projection to draw the patches like a champ! This will address both of the above issues and it can potentially make the second one much easier. We can run the Boolean operations before the projection on square shapes and then project the final shape in one go!

There is only one challenge: As of now I have no idea how to implement a new projection for D3 and I'm not sure when I get some quality free time to learn about it and implement it. Meanwhile I hope someone else figures this out!