Jump to content


  • Posts

  • Joined

  • Last visited


Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

MangoFusion's Achievements

  1. Just another update on this... I've submitted a PR for the main ipv6 code, https://github.com/GarageGames/Torque3D/pull/1817 - this covers core ipv6 functionality. As before, the master server at https://github.com/jamesu/PushButton-Master-Server/tree/ipv6_support/ can be used to test returning ipv6 addresses. Since i'm being cautious with regards to compatibility, I've set ipv6 to be disabled by default in the PR (i.e. the server won't listen on ipv6 and you won't be able to query ipv6 servers), though it can be enabled by setting $pref::Net::IPV6Enabled to 1 before setNetPorts is called. I'm still working on the master server packet challenge code, though this will take more time to finish as I need to refactor parts of the serverQuery code to account for resending normal packets. A test client which implements challenge packets can be found at https://gist.github.com/jamesu/fc806fd0cfd4ede92be0d5464ffd7334 .
  2. Just an update on this... What currently works: - Connecting to ipv4 addresses (yes, this is backwards compatible) - Connecting to ipv6 addresses - Browsing for ipv6 servers on a LAN - Working with ipv6 TCP sockets - Returning IPV6 addresses from the master server - Registering an IPV6 server with the master server What I'm currently working on: - Reworking the master server protocol so it uses challenge packets to prevent flood attacks - Testing everything
  3. MangoFusion

    IPV6 Support

    Hey guys, Just thought i'd let you guys know, i'm working on ipv6 support for the T3D (and T2D) networking. Current progress is available at https://github.com/jamesu/Torque3D/tree/ipv6_support . For the master server, i'm just modifying PBMS (since the GG one seems to have been lost in torqueland), available at https://github.com/jamesu/PushButton-Master-Server/tree/ipv6_support/ What currently works: - Connecting to ipv4 addresses (yes, this is backwards compatible) - Connecting to ipv6 addresses - Browsing for ipv6 servers on a LAN - Working with ipv6 TCP sockets What I'm currently working on: - Reworking the master server protocol to return ipv6 addresses (hopefully in a backwards compatible fashion) - Testing everything What I might be working on: - Improving the master server protocol to prevent obvious flood attacks For testing, if you don't have an IPV6 ISP you can just setup a local IPV6 network (e.g. using 2012::1, 2012::2, etc). Currently it is only known to work on windows as I haven't tested elsewhere yet.
  4. Probably related to the HW Skinning changes. I've tried in the latest development branch and your shape seems to load fine. If you have any more bad cases please post any relevant files so I can check.
  5. @JackStone Make sure you have the openvr dll in your game folder.
  6. Time for another update... Still working on controller support. Rendering of the controllers is in, just the interaction API needs to be worked on so you can interact with things in the game world. I'm also working on a new type of object from which the tracking origin can be based (for the controllers). This will probably also be incorporated into the player / vrplayer code. Its come to my attention also that the reflection code is a little broken. Thankfully I finally have a solution for this and will be incorporating it into the repository soon. I'm currently aiming to do a rebase of the branch to the latest development branch to incorporate fixes introduced to the current code. Also aiming to speed up development so I can get something incorporated into a pull request before the end of the month.
  7. Another update.... Finally have a fix for both the scattersky and the lensflare - turns out torque3d likes to assume you have nice on-center projections when changing the frustum distances, which in the case of VR is not the case which was breaking the scattersky. Similarly the lens flare code was not projecting the suns position correctly for both eyes, nor was it correctly taking into account the center of the projection when calculating the flare direction. EDIT: While there was an issue with side-by-side rendering this should now be fixed. Separate render targets also work properly. Of course there is a fair bit of optimization to do, but my interest at the moment is just to get stuff working and optimize the hell out of it later. At the moment i'd like to get controller support in soon, but i'm aware at the moment this stuff isn't too accessible for everyone else, so i'm looking to make a sort of WIP-demo or perhaps just resurrect one of the old oculus demos. Keep your eyes peeled I guess!
  8. Time for another update.... I've changed the scene & gfx code so there's a notion of a head matrix position. This is intended to be mainly used for the diffuse camera transform to calculate metrics - so stuff should appear the same LOD and whatever in both eyes. My current attention has been drawn to the skybox & scattersky objects. Currently bth these objects have bad problems with stereo rendering. Firstly the skybox moves around too much which can cause motion sickness. I've determined this is a problem with torque and not the stereo rendering code, as this issue can be seen when moving the camera up and down normally. This is quite bizarre and not how i'd expect a skybox to function. Secondly the scattersky sun is duplicated in both eyes and doesn't appear to work properly with the stereo rendering. Quite honestly I have no idea how to fix this. Thirdly the lens flare is similarly broken to the scattersky. This time the issue is with the projection into screenspace which causes the lens flare to be duplicated in both eyes. There was code to fix this for DK1, but since we now get the projection parameters and the camera offset from the openvr library, this workaround no longer works. So basically the lens flare code probably has to be rewritten. As of yet I haven't noticed any other effects which have problems with stereo.
  9. Time for another update... I've finished basic support for steamvr overlays - these are the overlays you can see in either the dashboard or overlaid on top of the scene. They'll usually remain present even if the HMD looses tracking status. You can use these to implement basic GUI overlays and such. AFAIK they don't interact with the scene itself, so I might have to make a separate but similar object for that - or you can just use whatever 3d gui solution is the rage for t3d these days. As mentioned previously still working on fixing the camera so certain effects work properly in stereo.
  10. Ok guys another update.... I've fixed a problem with the eye transform being off. This was a case of the multiplication for the eye transform being in the wrong order - a big screwup on my part unfortunately. This has been fixed in the branch. I'm currently working on overlay support and also fixing a slight issue with the camera code for some object render functions - basically since the DK2 stuff the camera view has technically been a bit off which is causing some things like the light flare to render incorrectly in some cases. @HebbleWhite Should release a binary within a week or two with any luck. Depends how long it takes to fix this camera issue.
  11. @Paul, Barrel distortion is handled by each respective VR library these days. The HMD will receive the rendered output with distortion applied by the library.
  12. Paul, With all due respect I'm not a mind reader. When you say you get unresolved externals, how could I possibly help if I don't know what they are? In any case I have put some binaries for the D3DTest example at https://drive.google.com/file/d/0B9SPZhVNDK6BTThWVUp5cjZYeUU/view?usp=sharing - if those combined with the D3DTest game files dont work, my only guess would be your system or drivers doesn't support D3D11. On my system everything loads in d3d11 mode - no crashes. To be quite honest I dont really have much in-depth knowledge of why the d3d11 adapter code could be failing besides the absolute basics. That's more Timmy's domain.
  13. Do you have a stack trace of your crash? Tends to be more useful than the console log since that doesn't give any indication as to why it crashed (usually). Otherwise I havent a clue. :( If you grab the openvr sdk from https://github.com/ValveSoftware/openvr there is a demo project in the samples folder, "hellovr_opengl". If you can build and run that AND if it recognises your DK1, chances are it will work in T3D with my changes too (assuming you can get your stuff working with d3d11). You'll need a recent oculus runtime and possibly steamvr installed for that though, and given i've never used a DK1 I have no idea if that works with the current oculus runtime.
  14. The branch linked is just setup for openvr, not the oculus SDK (i.e. you only need to use the openvr sdk for this). Its possible to use oculus headsets with openvr provided you have the correct plugin installed - you just need steamvr installed and a recent oculus runtime installed. (see https://support.steampowered.com/kb_article.php?ref=3180-UPHK-0900 for more details). Dont worry, this stuff is still experimental - experience is bound to be rough. ;(
  15. Ok guys i've updated the branch with my latest code. Based on my testing head tracking appears to work correctly. Located as usual here: https://github.com/jamesu/Torque3D/tree/dx11_openvr In order for it to work, TORQUE_EXTENDED_MOVE needs to be set as well as the openvr code needs to be included - for cmake this is handled by the module_openvr.cmake which adds in TORQUE_OPENVR & TORQUE_OPENVR_SDK_PATH. Alternatively you can add the files and required libs manually, just include everything in openvr headers and lib/win32 (or win64 if compiling for 64bit). Also dont forget platform/input/openvr on the torque end. I've also uploaded an example game folder here which should have the openvr stuff setup provided you use the d3d11 display adapter (i.e. $pref::Video::displayDevice needs to be D3D11 and you need to have compiled in the d3d11 code): https://drive.google.com/file/d/0B9SPZhVNDK6BM3F1Z3JLTDdTY3M/view?usp=sharing Going to work on the overlays next. While there is already some overlay code present (mainly used for the metrics and dialog boxes) its currently not making any use of the openvr overlay API. Theres also still some odd things going on with the rendering which im looking into - might just be something using the wrong rendering target though i'm not sure. After that.... controller support. @PaulWeston I've just been using the project file generated by the cmake build system with "TORQUE_D3D11" set to true. I suggest checking out the game code I linked and seeing if there are any missing bits of code.
  • Create New...