[OX-548] Hack edge thickness in Windows

[tmbo]

[reporter="autoreporter", created="Thu, 28 Mar 2013 14:43:03 +0100"]

So as Daniel told me, setting the edge thickness of a particle Windows is not possible.
From time to time, I really need thicker edges though.
Here is what I would like to use instead:
Pressing "0" would increases the browser zoom level to 500%.
All controls would have to be scaled accordingly, or if that's not easily possible, not showed at all.
The viewport size would be set to 20%

Pressing "0" again would reset everything to where it was before. (Zoom 100%, Viewport size 100%)

Reported by: Kevin Boergens ([email protected])

Log Time

[tmbo]

[author="daniel", created="Sat, 6 Apr 2013 16:04:42 +0200"]

Norman Rzepka
What's your opinion on this?

[tmbo]

[author="normanrz", created="Thu, 11 Apr 2013 16:53:22 +0200"]

Personally, I don't think it's a good idea.

We can't really zoom the browser interface in a sensible way. Everything will get pixelated or blurry.
Also this hack might cost you guys more than getting a mac. Are the lines correctly displayed on linux boxes?

[tmbo]

[author="", created="Sat, 13 Apr 2013 18:39:14 +0200"]

I see your point. Perhaps my solution was also too local.
But I feel that by now this problem in general has become pretty dramatic.
On a Windows system, it is virtually impossible to find an edge in the viewport where it is not obliquely cut.
Take a look at this:
https://dl.dropboxusercontent.com/u/64223389/wherestheedge.png
Are you able to find the edge without zooming in? (hint: it's turquoise)

Best,
Kevin

[tmbo]

[author="daniel", created="Sat, 13 Apr 2013 18:44:16 +0200"]

Why don't you increase the particle size a tiny bit, in combination with a slightly increased route clipping distance this should clearly indicate where that edge is?

[tmbo]

[author="", created="Sat, 13 Apr 2013 18:49:22 +0200"]

Particle size doesn't have any effect on edge thickness.
Clipping distance doesn't have any effect because the edge is pretty orthogonal (and also it's on the value (40) that Moritz recommends)

Best,
Kevin

[tmbo]

[author="normanrz", created="Sat, 13 Apr 2013 18:53:06 +0200"]

Would it help to place a larger dot in the spot where the edge pierces the data slice?

[tmbo]

[author="daniel", created="Sat, 13 Apr 2013 18:54:47 +0200"]

I know that it doesn't have any effects on edge thickness but on the particle size, so I thought you would see the particles that belong to this edge, which would indicate where it is.

[tmbo]

[author="", created="Sat, 13 Apr 2013 18:57:40 +0200"]

I like your thinking
The dot should have the diameter that the edge would have on a working setup.
A little alpha might also help to discern them from normal dots.

Best,
Kevin

[tmbo]

[author="", created="Sat, 13 Apr 2013 18:59:39 +0200"]

@daniel: Yeah, that's true.. But I think that Norman made an excellent suggestion. I would be eager to see a demo version of that

Best,
Kevin

[tmbo]

[author="daniel", created="Thu, 25 Apr 2013 00:21:02 +0200"]

Unfortunately this isn't trivial, we would hava to calculate whether an edge cuts the data slice, 1. for every edge inside a tree, because the tree could cut the data slice in more than one spots, 2. for all three planes, 3. in EVERY frame.
This doesn't seem to be an appropriate solution.

Or do you know of a better solution for this kind of problem?

[tmbo]

[author="", created="Thu, 25 Apr 2013 10:36:11 +0200"]

Your solution sounds good.
Do you mean non-trivial in terms of implementing it or in terms of cpu load?

Best,
Kevin

[tmbo]

[author="daniel", created="Wed, 1 May 2013 13:04:28 +0200"]

Sry I missed your comment.
I mean non-trivial in terms of cpu load, just imagine a big tree with > 10000 nodes and what would need to be done in every single frame.

Give me one more day, I'm onto sth. there, seems like we'll be able to make it work

[tmbo]

[author="", created="Wed, 1 May 2013 14:31:54 +0200"]

Ah, I see your point.
I was thinking that per tree it's just an arithmetic operation, so it might be possible.
I'm not sure about that though.
Keep me updated how things are going

Best,
Kevin

[tmbo]

[author="daniel", created="Thu, 2 May 2013 00:25:02 +0200"]

Alright you can start chrome with the

--use-gl=desktop

flag (close all instances before doing so), which tells it to use native open gl drivers instead of chrome's own angle drivers, which will enable different line widths, but is terribly slow (5fps) for me with a NVIDIA GT540M.
Is that the case for you too?

That's a test page to test whether different line widths are supported, but you should also see it in oxalis:

http://alteredqualia.com/tmp/webgl-linewidth-test/

[tmbo]

[author="", created="Thu, 2 May 2013 14:27:07 +0200"]

Not bad!
On my Quadro NVS 295 it's 30fps.
I'll have that tip included in the Oxalis FAQ.
I think that we should revisit this topic from time to time but for now there are more urgent problems.

Best,
Kevin

[tmbo]

[author="", created="Thu, 2 May 2013 14:29:04 +0200"]

Oh, also ,what's the ratio between edge and node diameter?

Best,
Kevin

[tmbo]

[author="daniel", created="Thu, 2 May 2013 14:57:21 +0200"]

It's 1:4 currently.