add transparency on object level

[biasmv]

add transparency on object level

[kozmad]

I've slightly modified the code to display transparent object. My original goal was inserting transparent planes to mimic cell membrane. (pdbtm.enzim.hu) Loading polygons from files are in progress, but structure opacity can be modified (setTransparency). I've added a slidebar in index.html.

[biasmv]

Hi, I'm interested in getting this in. Could you send me a pull-request just containing the transparency changes you did? From a quick glance at the code: is it important to you to have per-vertex opacity values? Or would it be enough to just have per-mesh-geom opacity levels? In case of the latter, I would suggest implementing the opacity directly in the shader using a uniform. This avoids making the vertex buffers larger and doesn't slow the geom generation down.

Thanks for working on this!

Best,
Marco

[kozmad]

Hello!

I'll try to send. This is my first time using git-hub, It might take some time to send it.
I think per-vertex opacity is useful and needed for selecting substructures within a chain. Maybe I've not noticed something and your concept results in the same. My starting point was coloring. Theirs functions enables point to point color transitions, it'll be nice if alpha would behave in the same way. You have right, it increases allocated memory by 1.33 but I guess this is not a bottleneck. (or maybe.. ;) )
I haven' t opened a new issue for that, but I was wondering if it would be useful to implement a scripting layer as well, e.g. in Astex, JMol. It would make the usage easier for the non-coder users, wouldn't it?
And finally, is there any goal/milestone for this project? I mean, it try to approximate Astex or beyond, it aim at PyMol? I think publishing it in some paper would advertise it and it'd lead to a wider user and developer community as well. And users like me, could cite you when utilizing it into theirs websites.

Cheers,
Daniel

[sheeep]

Hi @kozmad

I'll try to send. This is my first time using git-hub, It might take some time to send it.

Nothing easier than that, just take a look at this well written howto article in the GitHub help center.

I think publishing it in some paper would advertise it and it'd lead to a wider user and developer community as well. And users like me, could cite you when utilizing it into theirs websites.

Either write an entire paper on biasmv/pv, or @biasmv creates a DOI for it as suggested a few times before. 😉

[biasmv]

Sorry, hit the wrong button. Didn't mean to close the issue :). Trying to address your questions:

thanks for sending the pull request. I'll look through it and add my comments.

Per-Object vs per-vertex opacity:

The way that I typically used viewers is to assign one opacity level for a part of the structure. In cases, when I needed multiple opacity levels, it was easy enough to just create multiple geometries, one for each opacity level. Now, that is not as flexible as having per-vertex opacity and wouldn't allow for, say, opacity gradients. But then again, I never needed that.

Having that said, I'm fine with adding the per-vertex opacity values. In the end, it increases size by 10% (there are already 10 floating-point numbers per vertex for the mesh-geoms).

One big drawback I see with the current per-vertex opacity is that it's very hard to get decent results without sorting the vertices by projected z-coordinates on the screen. When a triangle at the front gets rendered before a triangle at the back, the triangle at the back is not rendered at all, because it fails the z-test. Which triangle gets rendered and which doesn't is kind of random and depends on the order they were created. This leads to strange effects.

Now, sorting by z-coordinate is certainly feasible, but would have to be redone every time the rotation of the viewer changes and I'm kind of reluctant to do that in JavaScript

An alternative is to render each transparent object into a second framebuffer and then blend them together based on the opacity level. This works nicely when displaying as structure with a semi-transparent surface. For other objects it doesn't work as well because of the lack of intra-object transparency.

Scripting Layer:

A scripting layer could be useful. At the moment, my main goal for PV is to be easily embeddable into websites. And since people doing websites know their JavaScript already, adding a scripting layer wasnt' really on the top of my list. For now, it's probably easier to just add JavaScript functions that people can use to do whatever they need to do. If there is substantial interest by people to have such as scripting layer and someone is willing to implement it, I'm the last person to say no.

Roadmap:

You are right, there is currently no roadmap available online. I should probably sit down and put one up.

For me, the main goal is to have a decent viewer that people can embed into their websites. It shouldn't get in their way, render molecules freakishly fast, even on low-end devices. Good performance becomes more important now, that more and more people are using mobile devices to view websites.

My goal isn't so much to compete with PyMol, but rather to have a very solid alternative to Java-based viewers.

There are a few things I would like to in the viewer that are currently not available

• better support for animations
• rendering DNA/RNA in ribbon style
• integration with sequence viewers and other viewers of protein-related information.
• good performance and integration on mobile devices. Your work on gesture support is a step in the right direction there.
• support for rendering really, really large molecules (think HIV capsid) at interactive frame rates using some kind of multi-resolution approach. That would also require to define a new file format that allows for incrementally fetching molecular structures.

Publishing:

I have been toying with the idea of publishing, but haven't really gotten around to it. If there is demand and more people are using it on their website, I'll probably sit down and start to write a publication :).

Thanks for the DOI link, @sheeep. That's very useful!

Best,
Marco

[kozmad]

Hi!

First of all, I'm sorry my temporarily inactivity. I'm/will be on the continue the discussed tasks, but I was/am a bit busy.
Currently, I'm writing an article on a web server developed by our group, which utilizes you PV viewer. I'd be happy if I could cite your work. Is there any progress in getting DOI for PV?

Thank you for your help in advance!

Cheers,
Daniel

[biasmv]

Hi, you can follow this link to cite PV for now https://zenodo.org/record/12620.

Next time: could you open a new ticket instead of adding a comment on an already closed one? It's easier for me to keep track of open requests that way :).