[Turambar]

I uploaded the patch to a branch in github: https://github.com/andresi/xbmc
This way it should be easier to apply it (it's just the jaaps branch plus my patch)

I also added subtitle depth to Settings: https://github.com/andresi/xbmc/commit/c...7e7f8aeadb

[Turambar]

Is possible to add this code to master branch? Sorry i don't know how that get managed usually.

What sialivi said plus this code is not ready to be added yet. There is at least one known problem when one "half" of the gui is not updated and is getting out of sync. There is also some flickering screen problem mentioned by zpon.

I have fixed the gui out of sync issues as well as one instance of flickering I found. I'd appreciate it if anyone can help me test it and let me know if there are any more sync problems.
You can find the fixes on my branch: https://github.com/andresi/xbmc

[da-anda]

why haven't you created a separate branch for the 3D stuff? Having it in a default XBMC branch is not that good IMO.

[leechguy]

True... I have a Pull Request open from my master branch. Now every branch I create from the my master branch also contains the code of this PR which is annoying for as long as the PR is not merged. Of course there are ways around this, but if I had known then what I know now, then I would never have pushed the changes into the my master branch and issued the PR from there.

[da-anda]

Yep - as a rule of thumb - keep your master (and any remote/foreign branch you base on) clean and rather create a custom branch to add your changes there. Much easier to handle that way.

[Turambar]

why haven't you created a separate branch for the 3D stuff? Having it in a default XBMC branch is not that good IMO.

I don't have a lot of experience with git... I have now reverted the Frodo branch and moved the commits to a 3d branch.

[Splash44]

@Turambar: I've tried your 3D version and it's working very well. The possibility of changing the subtitle depth is functional and working great! Thanks.

[giaur]

I think 3d stuff should be included in mainline - is this stable enough? It's good to see 3d support for gui! Of course, I'm going to test this.

[edit]
It works, good job. Is there any keyboard shortcut to switch between stereo modes? 'y' does not work (no effect). Should I configure something to make it working?

Also, anaglyph modes don't work.

[Nogler]

@giaur

read this thread http://forum.xbmc.org/showthread.php?tid...pid1262704
You have to add the keyboard.xml

[giaur]

It works, thanks.

[da-anda]

I think 3d stuff should be included in mainline - is this stable enough?

I think pieh wanted to give it some more love in general, but he doesn't have a 3D TV, so he can't really test what he's doing. AFAIK he didn't consider it as "stable" enough to create a PR. He also wasn't sure if we couldn't save one rendering pass for now for the whole gui in total, as we don't have any depth information within the GUI nor any real 3D angle. Thus it would be sufficient to just duplicate the once rendered GUI, split it (or pick every second line/row depending if tab or sbs) and apply offsets for the 3D depth on screen. But this would have to be tested.

[giaur]

Ok, I only hope 3D stuff will stay maintained, because this is "must have" for users that have 3D monitors/TVs. I think there should be "3d" branch in official xbmc's git repository and it should be maintained (if not included in mainline). There is a lot of good work done and it definitely should not be lost (I can imagine new xbmc version withoud 3D support because there is nobody who can merge 3D with latest xbmc sources). After some testing, I can say it works quite good and stable.

he doesn't have a 3D TV, so he can't really test what he's doing

I know this makes work harder, but still possible. The rules are known (how to make half over-unde or half-sbs image) and there are many people here (including myself) who can test all stuff.

Some issues/suggestions:
- sometimes xbmc starts with over-under splitted gui and it shouldn't
- anaglyph modes don't have any sense (my opinion) but maybe someone will find them usable, it seems they don't work anyway
- todo: correct scaling ou/sbs movies, I mean they should be zoomed correctly, depending of selected 3d mode
- gui depth/z order for controls. It will be very exciting to have all gui in 3d (different Z position for different controls). This feaature will make xbmc really unique, I don't know any good software providing this. And I'm sure there is no software like this for Linux/Mac. There are 3D players for Windows, but they are paid and gui is really ugly comparing to xbmc.
- subtitle depth settings should be placed on sound/subtitle settings window, this option should be disabled if 3d mode is not enabled

[da-anda]

the only thing I can imagine for a additional z index/depth are dialogs - so that those pop out. But this also depends on skins if their dialogs are really dialogs and f.e. not sometimes a sidebar or something else (like in lightbox/nbox). So this information would have to be added to skins and would require additional changes to the skinning engine.
And testing the 3D effect without being able to watch it in 3D is not really possible - you can't really judge the quality of fonts, thin lines, subtitles etc - and having to depend on other guys to test and give feedback for every small change is a pita.

sometimes xbmc starts with over-under splitted gui and it shouldn't

you probably closed XBMC in that mode?

[giaur]

I agree, skin-level support would be the best solution probably but this forces to make changes in skin engine (to make possible to define Z position for each control, not only X,Y, widthth and height). The main question: are skin developers or other xbmc developers interested in this and have enough time to take a look into this?

I don't know what's your "roadmap" for xbmc, is there any chance to improve/create serious 3d engine (maybe with more than only one persion working on this) in near future and maybe include it to mainline later? (just the same as pvr support).

[da-anda]

there are no plans for a real 3D gui as we don't see a big benefit of it (would probably only require more cpu/gpu which we tend to avoid aiming for lowpower devices) and we unfortunately only have one main GUI dev (pieh) + some randomly poking around (AFAIK).