Re: Directx Download
Amabella Tevebaugh
This to me sounds like something you could post on protondb.
There are also different Proton builds (GloriousEggroll, others) to help.
I personally have not had major issues with DX11/12 games on Fedora, but again my install is different from yours. I do also have an Nvidia system(GTX970) and an AMD system (RX5700XT).
I have the same issue with my installation. If I was not using my machine to run my Oracle databases test environment, I would already installed another linux distro, because it seems that no one cares. As stated by other users, directx12 works fine on other linux distributions, the issue is Fedora related.
We always complained how bad linux gaming was, that no one cared about gaming on linux, and when we finally got a big company developing solutions for more games be available on linux, we bump in a wall in the linux side.
command and conquer generals and C & C generals zero hour, having difficulty running the game as its coming up with an error for Directx 8.1 required. I haven't got any issues running red alert 3 or other in the series. I have re downloaded latest directx but not having much luck. has anyone else had a similar experience?
The problem is that the "or higher" refers to higher versions of DirectX 8/9, not higher versions of DirectX beyond 9. The game can't actually use the DirectX 10/11/12 that is installed on windows machines by default nowadays, so updating to the latest DirectX will not help you.
It seems Generals, specifically, has an issue with DirectX that is caused by a malfunctioning dll in the game folder that was actually left there from testing. If you go into the game folder, and delete the file "dbghelp.dll" there, this problem should be resolved.
I am having the same issues but the solution listed did not help. I installed the patch listed and It did not work. I still get the directx error. Any help would be helpful at this point I am out of ideas
Is there any plan to support even the DirectX Visualization? Developing another dll for rendering such as TKDirectX instead of only TKOpenGL?
I need to integrate the OpenCascade view into WPF application, as with DirectX and Direct3D rendering it is possible to avoid the airpsace issue, I'd like to have this kind of rendering even with OpenCascade.
Hi Sergey
Could you expand a little what you mean by "tend to target the third-party 3D visualization libraries, instead of implementing new in-house 3D renderers"? Is it already planned? How soon? Which libraries are you looking at?
Sergey,
I think a third party rendering engine is the right way to go. Rendering technology develops very fast. It looks like a different business. I saw huge engines. OCCT's strength on the other hand is in geometry and modelling. This changes slowly.
It would be great if you could make better modularity between geometry and renderer. It should be relatively easy to change the default renderer. It would only make OCCT more valuable. Some people might need fast animation. Some might need a ray tracer for presentations.
I do not think it should be a runtime switch. Instead it simply should be clear how to modify the code to compile another OCCT/Renderer adaptor
Thanks
Nick
I'd like to try a way for using VTK for rendering, is there any plan to integrate it in the OCCT Release? Which is the right way for extending OCCT rendering for providind a different way for rendering? It could be implemented using VTK, DirectX, or another rendering Engine.
Could you add a sample for implementing such extension? Or describe which are the main functions to be implemented? I think I must create another dll like TKOpenGl.dll and implement all the functions contained? Which is the simpler way for doing it? Is there a simple interface to implement for using another rendering engine? Could you add a guide for this or a sample?
It will be very usefull if you'd provide another alternative rendering way, adding for example a rendering with VTK.
Thinking about smoother integration of an OCCT 3D view into a WPF application, have you ever considered rendering an OpenGL scene to a frame buffer object (FBO) and then drawing its content onto a WPF control? This looks really a reasonable alternative to a separate Direct3D renderer, and it should resolve the airspace issue - certainly, at the cost of redundant frame buffer copying.
Maybe you can use both worlds instead of choosing one.
It seems to me that's the way the ANGLE projet - Almost Native Graphics Layer Engine (OpenGL binding on D3Dx) - use to performs webGL on windows inside firefox is right.
You could add support for DirectX rendering using the OpenGL extension WGL_NV_DX_interop and WGL_NV_DX_interop2, this was developed by NVIDIA and now is supported even from the other vendors like AMD and Intel, so it's quite standard right now for the new graphic cards. As you can see from
This will add the way for rendering using DirectX with very low cost.
The rendering system made with OpenGl remain the same, but it will be possible to redirect the output to DirectX target as reported in this sample
And sample situations where Windows users (or at least you personally) could benefit from DirectX support would probably put more light on your continuous efforts in this area. Well, integration with WPF is an example, but there are some alternative solutions that do not require any changes in OCCT.
I need to make UI composition with graphical components strong integrated with graphic area, like many cad developed new version with complex UI WPF composition using different controls, ViewCube, Dinamic input, Marking Menus, HUD for display infos and make decision and interaction, complex tree controls in overlay integrated with the cad graphic area.
Using WindowsFormsHost or HwndHost there is the airspace problem, for WPF the graphic area is a totally black hole, it's not possible to make transparent controls over it, not possible to apply effetcs or transitions and have fully integration with the WPF UI Composition.
Even when I open other modal windows on top of the graphic area I have rendering problems, as they are rendered behind, and I need to stop the redraw of graphic area.
I have tried to made a gray fade for the application when I need to disable editing but this prevent HwndHost working over it.
Now I use a Overlay transparent window over the graphic area to place some transparent controls as in this sample
-directx-intero...
but there are syn problems if you use different regions with navigations, and the windows from time to time have rendering problems and this not solve the problem to have effects or transitions. And I think I have performance issue as there are unneded redraw of graphic area.
Using DirectX rendering it could be possible to render with Direct3D and have fully integration with WPF as shown in this article
+and+WPF (with different samples)
As the WGL_NV_DX_interop extension seem to be supported now from all major Graphic vendors I think it could be approved soon like a OpenGL standard, from the sample it seem it need a little work to make this works, so it could be an alternative for rendering target on Windows OS. Than you could provide with your package a WPF control that embed this 2 different way:
1) Direct3D based control using DirectX interop for rendering
2) HwndHost control with transparent Overlay Dialog on it
When we developed WPF sample in OCCT, we have discussed (though did not had time to try) one more possibility: to render 3d scene into an off-screen buffer and then map it as bitmap to the WPF window. Do you think it would be feasible?
Just to make things simple and clear for everybody, it should be noted that the purpose of WGL_NV_DX_interop/WGL_NV_DX_interop2 extensions is to access DirectX resources (such as vertex buffers and textures) from OpenGL. This becomes important if you have to mix OpenGl and DirectX rendering in an application, and this is obviously not the case either for OCCT or for your application.
Of course, this can be also used to send OpenGL rendering results to DirectX - but...what is the difference between this - and simply rendering to a pixmap and drawing it on a window?
Do we really need DirectX for that? This is the question.
How will you render to a window without using old windowsforms technology without WindowsformHost and HwndHost ??? Of course without creating a new image at every frame and copy all the pixels with great performance problems ?!?!
If you produce only old windowsform style application there is no matter to go further with this discussion.
As is very difficult to create an extension to OpenCascade for rendering with another graphic engine, I think that probably I'll go using another library instead of OpenCascade, or I'll search for a better solution by my own and as you don't see any benefit in it I will not share with you, thanks.
Obviously, there is some misunderstanding between us.
My only concern was to double-check that DirectX is really a reasonable solution for embedding OCCT 3D viewer into a WPF application.
I admit that we might lack some experience in this particular area, and this is exactly the reason why I started this discussion. Your opinion is really important and helpful for us!
And certainly you are completely free to share the results of your development or not.
In case if you still want to contribute to OCCT development, can you please report an OCCT Mantis issue for this improvement and follow the contribution workflow?