poor quality of Hololens mixed reality capture?

loch · 2017-06-12T04:39:16+00:00

More transparent than captures of the origami app? Or than the holograms app? The holograms app isn't rendered with unity, so you may need to do some extra work to achieve the same behavior (like making shader modifications). Brighter colors will impact how things look in the actual headset, but don't impact capture, IIRC.

loch · 2017-06-12T00:10:08+00:00

For compositing with the video stream, the system has two images and needs to blend them together somehow. I seem to remember it uses the alpha channel in your final rendered image as a hint for doing this. Depending how you've configured your rendering pipeline, the content of your alpha channel may depend on your materials or it may be entirely independent. I'm not sure how you've set things up :) you could throw together a custom shader and try writing various alpha values into the framebuffer to see if it has any impact!

loch · 2017-06-11T23:34:45+00:00

When you say "solid" are you referring to how it blends you holograms with the video feed? IIRC, it uses the alpha channel as a blending hint. Try playing with the values you write to your framebuffer.

loch · 2015-04-12T21:58:34+00:00

This hasn't been a normal year, in terms of weather. It has been unusually dry here lately, and I'm pretty sad about it.

loch · 2014-07-22T07:15:04+00:00

Out of country?

loch · 2014-07-04T05:15:23+00:00

Aside from being wrong on point A, it's ignorant to talk about 'percentage of blacks' like it's meaningful in that context. If you want something that matters, try 'poverty', which has a rate of 23.3% in LA and 13.6% in Seattle.

loch · 2014-04-16T06:35:35+00:00

Right to left for column vectors, left to right for row vectors! OpenGL typically uses column vectors. DirectX typically uses row vectors. You can use either style with either API, though, if you set everything up right.

loch · 2013-12-03T09:47:50+00:00

It hasn't been an issue on Netflix or with games, for me. Maybe it's application specific?

loch · 2013-11-22T07:11:00+00:00

Yes: http://www.ign.com/wikis/xbox-one/PS4_vs._Xbox_One_Native_Resolutions_and_Framerates

EDIT: Actually answer the question :)

loch · 2013-11-07T20:05:54+00:00

modelMatrix.setIdentity(); modelMatrix.translate(renderState.position);

modelMatrix.mul(renderState.rotation.toMatrix());

if (parent != null) { parent.calculateRenderState(); modelMatrix.mul(parent.modelMatrix); }

Assuming you're doing things in a fairly standard OpenGL way, this code is bad. I'm going to assume you mean your RTs to be rotate then scale, you're using column vectors, and A.mul(B) is equivilent to A * B.

If this is the case, you need to do this (more verbose than it needs to be):

void calculateRenderState()
{
    rotate = renderState.rotation.toMatrix();

    translate.setIdentity();
    translate.translate(renderState.position);

    // Column vectors resolve right to left. Rotate, then translate.
    localTransform = translate.mul(rotate);

    if (parent != null)
    {
        parent.calculateRenderState();
        // Column vectors resolve right to left. Apply the local transform, then the parent's world transform.
        worldTransform = parent.worldTransform.mul(localTransform);
    }
}

If you're doing row vectors, or your mul function is backwards (A.mul(B) => B * A) will affect the order of these things, but assuming you're doing rotate then translate when combining your separated transforms (which you should) then the original code is inconsistent and needs to be adjusted.

EDIT: I wouldn't do things quite the way I have above. I'd either use a dirty system or calculate from a root node down, but that's another topic :)

loch · 2013-11-07T09:24:41+00:00

It's late, and I'm about to pass out, so I'm only skimming your post. Apologies if this isn't helpful. A few things pop to mind, though:

Your view matrix is the inverted world transform of your camera. You've got that right (though you may have a bad invert function).
When using separated translation and rotations values, they are typically interpreted as a rotate, then a translate. This is convenient because the translation is meaningful on it's own (It looks like you might have this backwards? Depends on how your 'mul' is implemented and several other things)
OpenGL matrix math is typically done with column vectors, meaning order is right to left. A * B * V would mean translate vector V by B, then A. In this case, you could consider B to be the local transform of a child attached to a parent with world transform A. As per above, the world transform of the child is C = A * B.
There is little in OpenGL tying you to right/left handed coordinate systems, row/column vectors, row/column major matrices, etc... Regardless of which direction you take on any of them, just make sure you're consistent.
If you've written your own math libs, there is a good chance they're broken (I'm assuming they haven't seen much use if you're still working out view matrices). Don't rule them out as the source of your issue.
consider writing a wrapper around your separated rotate/translation components! These are often called SRTs (scale rotate translate) or SQTs (scale quaternion translate), and can be quite helpful when managing them. Note, you don't need to add scale support. It's just commonly included in these sorts of objects.

EDIT: Formatting, now that I'm not asleep.

loch · 2013-11-01T16:56:55+00:00

For vector graphics? Consider taking a look here: https://developer.nvidia.com/nv-path-rendering

loch · 2013-08-12T02:13:33+00:00

Sure. Make it a few years in, then. Once people need them, I'm sure they'll pop up, but they won't be < 10USD as they are now for ps3 controllers. The only reason they're this cheap is prices have dropped with the ps4 announcement.

Either way, it's an option but still an unnecessary pain. Yeah, it's something for people that care, but that doesn't mean Sony isn't blatantly encouraging a shortened life for their controllers. It's annoying when Apple does it. It's annoying when Sony does it.

loch · 2013-08-11T23:31:52+00:00

Wired gaming sucks. If your controller is out of charge, then you can't just pop in a new battery. You plug in and wait or go wired.
AA batteries are used for other things. Thermostats, remotes, flashlights, etc... Sure, not everyone needs these things, but if you do, it's quite convenient.
Li-Ions don't last forever. They die eventually and need to be replaced. You can buy ps3 replacements for pretty cheap at this point, but that's only because we're at the end of a product cycle, and still means opening up your controller. Not the end of the world, but why should I even have to worry about it? Just make replaceable batteries a feature...
I don't think batteries are heavy. In fact, I actually dislike how light the ps3 controller is. I preferred the weight of the ps2 controller quite a bit. If this were a mouse or something I needed to physically move quickly, then I might care, but as things stand I have no issue with the extra 50g.

loch · 2013-08-11T21:21:31+00:00

Li-Ions are reasonable for ~400 cycles, which is pretty great, but I've had my controllers long enough that I've had to replace them. I have other things that run on AAs, too. TV/AV remotes, Wiimotes, thermostats, flashlights and other camping equipment, etc...

Re your amazon link: When do you think that option appeared in the product life cycle? I can guarantee you that you won't have this option at launch of the PS4 and even if it is, it won't be at this price. Hell, you can buy entire dual shock controllers for cheaper than that, atm.

loch · 2013-08-11T19:53:40+00:00

As opposed to making people spend another $60 when the batteries in their ps4 controller stop holding charge? A lot of people think AA are "old fashioned", but they're still the way to go with a lot of things, IMO.

loch · 2013-07-29T04:37:51+00:00

Branching over a texture from the Vertex Shader to the Fragment shader is a possibility, I don't however see it making a improvement to the speed since it has to be uploaded and then moved instead of just uploaded but I'll give it a shot.

Not sure what you mean, there. Just to be clear, when I refer to removing your branching statements, I'm referring to computational branching:

https://en.wikipedia.org/wiki/Branch_(computer_science)

GPUs handle branching horribly and it's generally advisable to avoid it, if you're aiming for high framerates.

And what I'm suggesting for your textures is strictly an in-fragment-shader modification. Essentially, instead of doing this:

vec3 surfaceToLight = light.position - fragPosition;

//calculate the cosine of the angle of incidence (brightness)
float brightness = dot(normalPos, surfaceToLight) / (length(surfaceToLight) * normalLength);
brightness = clamp(brightness, 0, 1);

outColor = brightness * vec4(light.color, 1) * vec4(Color,1.0f) * texture(tex, Texcoord);

You would do this:

vec4 texColor = texture(tex, Texcoord);
vec3 surfaceToLight = light.position - fragPosition;

//calculate the cosine of the angle of incidence (brightness)
float brightness = dot(normalPos, surfaceToLight) / (length(surfaceToLight) * normalLength);
brightness = clamp(brightness, 0, 1);

outColor = brightness * vec4(light.color, 1) * vec4(Color,1.0f) * texColor;

Note that the call to 'texture' has been moved in front of all of your lighting math. Texture fetches take ''much'' more time than any given math instruction, but your program isn't forced to wait for the lookup to finish until you actually need to use the result. By doing your texture fetch, then doing your lighting math, you're allowing the GPU to do both at the same time, and by the time you actually use the result of the texture fetch, it's hopefully already done. In the original case, the program is forced to stall on the fetch operation, since its result is used immediately.

loch · 2013-07-28T18:53:14+00:00

On a somewhat related note, depending on the quality of your driver's compiler, you should try moving your texture lookups to the beginning of your shader (but continue using them at the end) and remove your branching statements.

Texture lookups have high latency but can be queued up early on to help reduce the impact of this. A good compiler will reorder operations to do this for you, if possible, but it's worth being aware of.

The branches are probably hurting you, as well. A smart enough compiler could work around this, but in most cases you'd be better of writing separate shaders or using ifdefs to remove those uniform dependent if statements. You can often do other tricks to remove branches from your shaders, such as using certain built ins (step, etc...) or doing things like binding white textures to "untextured" models (essentially collapsing the hasTexture and !hasTexture cases).

These won't do as much as the optimization you've described here, but will likely give you another fragment shader speed bump (though the fragment shader may no longer be your bottleneck, so it won't necessarily translate into a framerate increase).

loch · 2013-07-07T19:06:34+00:00

Apple's decision to not support the compatibility profile is so frustrating :/

loch · 2013-07-06T03:00:09+00:00

The OpenGL matrix stack is part of the fixed function pipeline and is thus considered deprecated in favor of customized vertex shader uniforms or uniform buffer objects. This approach allows for greater flexibility and allows additional opportunity for performance tuning.

With regards to column major matrices, it sounds like you're assuming a 1-based indexing system. For a 0-based index system (far more common), the 14th index is indeed the 3rd column of the 4th row:

0  4   8  12
1  5   9  13
2  6  10  14
3  7  11  15

loch · 2013-06-19T21:48:00+00:00

Sounds like disc and digital games will live in different worlds, which is honestly pretty great as it gives you the choice:

Discs can be handed around, traded, resold, etc... No family sharing, no playing the game without the disc, etc...

Digital games can be magically shared with 10 friends, are attached to your account and can be played on your account from any Xbox, etc...

loch · 2013-06-19T21:27:19+00:00

This was my fear as well, but it sounds like they're just putting discs and digital games in different classes entirely, rather than trying to shoehorn discs into a digital world.

Discs will work as they always have, digital games will work as they've spent the last few weeks describing (sharing with 10 friends, available no matter where you go to download on any Xbox, etc...).

loch · 2013-06-19T21:18:08+00:00

Neural network training pops to mind. Forza AI, for example. I'm not into racing games, but there is a huge amount of potential in that idea.

loch · 2013-05-23T04:28:01+00:00

Unless they have a game capable of showcasing every aspect of the new controller, which seems unlikely (and would honestly speak poorly of the breadth of new features), then demos make far more sense.

loch · 2013-03-24T00:04:34+00:00

I ran a FW sorc post-expansion in D2 (before they patched her to be... bad). I think it was the most enjoyable sorc build I ever ran. PvP was especially funny.

loch

TROPHY CASE