kit-ipe / wave-client-renderer Goto Github PK

Example:
The spatial domain [0:1] should map to [-2m:2m]

Axis and measuring can be done upon this work. This should be compatible with the non isotope resolution of 3D data voxel.

Related issue:
#21

some slight additions:
Surprisingly, we ran again in the insidious “too many texture units problem”, which got fixed only with manually setting the texture unit number in the second shader code from 32 to 8 , Confusingly, we saw in the github logs that you added code here for addressing this automatically?!?
Secondly, the GUI elements looked exactly like before , therefore both problems let us suspect that we either ran on some older code base or do something seriously wrong… ;)

Goal: the visualization should not dissapear and should allow user to dive into the 3D data.

Idea:

1. Setting the bounding box according to the camera status.
2. ...

Once in a while data is not load correctly and a few slices contain garbage data with expected results, as seen on the left side:

Hitting F5 resolves it but it's still not a nice experience. Nevertheless #34 is more important at the moment, so this is just for the record.

Zoombox breaking
The following API endpoints stopped working:

setZoomXMinValue
setZoomXMaxValue
setZoomYMinValue
setZoomYMaxValue
setZoomZMinValue
setZoomZMaxValue

USCT group has implemented this feature and should be merged here. Awaits Alexey and Torsten on this.

Currently renderer assumes voxel is a uniform cube with same resolution in all dimension, but several data sources has voxel with different resolution in different spatial dimension.

A solution to accomodate this non uniform voxel resolution need to be done ;)

whenever we change the size, the volume bleeds.

This is due to upscaling and downscaling of texture map in GPU. I'm not exactly sure what's going on inside. But this seems to be the case. What I found out is GPU does a bilinear filtering on the texture.

One way to solve this is to add extra process to correct the cube edge in shader.

As long as this is not solve, setRenderSize() method is only for debugging purposes and not intended for production.

Once zooming in too close on one particular side a weird artifact appears as shown here:

This needs to be improved, currently sometimes the user is left hanging and additional "magic" mouse clicks are required to make it work.

Maybe it is caused by racing conditions of the callback function.

Clear separations between the callback of functions.

Volume not translating on right click drag. It used to be possible before

your latest two commits introduce a bug.

THREE.WebGLRenderer 70
volumeRaycaster.js:681 Core: setTransferFunctionByColors()
volumeRaycaster.js:665 Core: setTransferFunctionByImage()
volumeRaycaster.js:675 Uncaught ReferenceError: transferTexture is not defined

So far the rendered volume suffers from aliasing effect.

1. we will need to implement super-sampling method to remove the jagged edges.
2. implement a stochastic random rays to remove moire effect
3. implement other AA filter such as morphology filter, etc.

When users perform panning with their right mouse click, the object is displaced and moved further away from its point of origin. It will be great to place a reference symbol at the origin to give users a hint of the origin's position.

You can enable the panning in the core.js file:
this._controls.noPan = false;

The right-click panning happens in the TrackballControls.js.

So far, we're just stepping through every pixels on the view plane and trace the rays. Well, this is fine for showcase, but should be sped up somehow.

1. Probable way is to use kd-trees to identify the region of intersections and traverse through this tree.

container is probably the most generic and worst choice for an id specifying the WebGL view …

I tried to install and this requires Three.js. I think its worthwhile to include this in the README.

Sometimes the colour map switching does not work. This was seen in Firefox.

Uncaught TypeError: THREE.OrbitControls is not a function

Currently the slicing functions works only in x, y and z direction, this is a limitation that we would like to remove. The goal is to have an arbitrary slice on the 3D object.

This would be a beneficial feature for feature extraction or data classification.

This should allow multiple bandpass implemented.

http://www-pequan.lip6.fr/~tierny/stuff/teaching/tierny_intro_vol_rend09.pdf

Cannot import Cross origin images

Currently, one can only change the shader by changing the shader name in the config file. One should implement a dropdown menu that can choose various shaders available. (reload the shader and preserve the settings and view status)

The bug fix earlier (4f6cc08) introduced the asynchronous loading of the slicemaps (core.js). However, the legacy approach still loads the slicemaps from volumeRaycaster.js and needs to be removed.

Well, you might blame the browser compatibility issue, but the weirdest part is the earlier version of tomo_raycaster2 worked on the same platform, but the newer version does not. Seems more like a bug to me.

I pinpoint down the commit to this
aae34c4

After that commit, firefox is unable to render anymore. Before that everything is working fine. I cannot debug it now as it looks like a big commit with only one line of commit message.

Currently we implemented an opacity transfer function that takes the size of the object into account (negative exponential function), but not the gray value (intensity) of the 3D data itself.

Implement additional opacity transfer function that takes the gray value intensities into consideration.

The colormap dependencies have to be governed in a better structure. For now, there are too many weird external links that are not reliable.

We should first remove the all the codes related to colormap and plan a feature release.

I always wondered why I saw some weird artifacts on the surrounding box. Turns out it's data from the opposite side of the cube. Here's an example, the full (but slightly cut) volume on the left and the volume sliced towards one side on the right. Circled in red is the data and its origin:

Can't find anything quickly but I'd be interested in API calls and options to the renderer constructor. It's a pity, I had to find out how to enable the ISO surface rendering by reading the report ;-)