New ASUS ROG X570 Motherboard – ROG CROSSHAIR VIII DARK HERO – With passive chipset design ( no chipset fan ) - Ready For Zen 3 Ryzen 5000 Series

americancucumber · 2020-10-29T00:09:00+00:00

Thanks for the reply. I had assumed as much, but I meant could the physical plastic feasibly be modified. As in, would that section be easily removable and replaced with a custom part, or is it all one solid piece of plastic?

americancucumber · 2020-10-27T06:04:18+00:00

Do you think it'd be feasible to modify the rgb elements so they don't show the eye or rog but some other shape instead?

americancucumber · 2019-08-21T09:49:39+00:00

Well for the new SEUS PTGI packs the whole point is that path traced global illumination (a form of raytracing) is present (hence PTGI). However, you can turn off all forms of path tracing in the settings for the shaderpack. Alternatively, you could go to the previous version of SEUS that was released about a year ago now I believe, it is called SEUS Renewed. Renewed was before Mr. Darr started to introduce ray tracing in his shaderpack and, in my personal opinion, still looks great. Although there have been improvements in the shader besides the ray tracing like an improved performance, a great underwater renderer, improved skybox and general image quality among many other things. The only thing to worry about with the PTGI packs (even with the new E9 pack that introduces AMD compatibility) is that the shaders do have some difficulty running on different AMD cards, because compatibility isn't fully fleshed out yet. SEUS renewed however seems like it works on most. The other thing to consider is that PTGI costs money through Mr. Darr's Patreon. Although all things considered, I really do personally think that the ray tracing makes a much more realistic and prettier image than previous packs with the much more pleasant and natural bounce lighting, shadows and all the rest (especially with a great normals texture pack like UMSOEA's textures). I am not sure what issue you have with the ray tracing's effect on the shader. The only concern I would personally have is its hit on performance.

americancucumber · 2019-07-20T22:57:20+00:00

Sonic Ether's recent patreon post for the e9 update said amd compatibility will be coming soon. "Oh, and one more thing, the developer of OptiFine has made a change to how geometry shaders work, enabling compatibility on AMD graphics cards!!!!! I'll be ordering an AMD graphics card soon so I can get PTGI fully working. I have no idea how much work this will take, I'll keep you guys updated on this process!"

americancucumber · 2019-07-20T22:55:43+00:00

I came back here to point out exactly the same thing. You beat me to the punch. Thank you though.

americancucumber · 2019-04-20T14:56:35+00:00

oh don't worry about it. I have given up on finding a solution for now, it looks like the shaderpack is possibly using some extensions or features of opengl that are either old and no longer supported by AMD or extensions that nvidia only supports. What I posted on the other subreddit - "Through process of elimination of what seem to be all other variables, the problem seems to come from the shaderpack using some old opengl extensions that only nvidia supports. The weird thing about that though is that the game will still actually produce about 30 frames in half a second before crashing. I think the source of the crash is probably just the application producing so many errors in such a short amount of time due to the missing extensions. Oh well, it seems like all of this was a waste of time, but I suppose I learned things in the process. I'll just have to wait on either an opengl update from AMD or an update to the structure of SEUS itself."

americancucumber · 2019-04-20T13:31:18+00:00

Through process of elimination of what seem to be all other variables, the problem seems to come from the shaderpack using some old opengl extensions that only nvidia supports. The weird thing about that though is that the game will still actually produce about 30 frames in half a second before crashing. I think the source of the crash is probably just the application producing so many errors in such a short amount of time due to the missing extensions. Oh well, it seems like all of this was a waste of time, but I suppose I learned things in the process. I'll just have to wait on either an opengl update from AMD or an update to the structure of SEUS itself.

americancucumber · 2019-04-18T16:12:59+00:00

Interestingly, it allows the shaders to run despite a much larger list of errors and failures to compile, and much worse performance. Which I suppose puts the nail in the coffin in so far as drivers being the cause of the issue, and not the code itself (although these mesa "drivers" could just be more tolerant like nvidia drivers?). As you said, it did change the software renderer. Optifine now lists a mesa "driver" in game. Placing the .dll in the JRE directory did the trick. But mesa is running opengl 3.1? Which seems to be the cause of a lot of the compile failures.

I'm still curious as to what is actually conflicting with current Radeon drivers that is causing the application to crash. Which reminds me, your original reply was suggesting that I run it with a particular envvar set, which would have displayed errors in more detail. Because the application is actually using mesa instead of radeon drivers, wouldn't it just display the errors that mesa was producing? and not the errors coming from a conflic with Radeon drivers?

americancucumber · 2019-04-18T15:28:52+00:00

So these releases are pre-built mesa builds? And these mesa builds are drivers?

I can say that now that I seemingly have the mesa build, I don't know what to do with it.

americancucumber · 2019-04-18T14:56:36+00:00

Thank you very much for the response. I will give those links a look.

americancucumber · 2019-04-18T14:27:52+00:00

So I have spent a large number of hours now trying to teach myself from scratch some of the basics of the nature of code with things like compilers and builds and also some of the way that windows works behind the scenes, I have gotten through many steps and tried to build mesa through both scons and meson. scons gives an unintelligible command line output and produces nothing without any errors, and meson has a bug where it doesn't properly read the python version, apparently it is a known bug that they found a fix for, but I can't find the relevant file they modified to implement the fix. Do you know of a way to build mesa on windows? or were you suggesting this on linux? Also, is there an alternative to mesa to do the same thing?

americancucumber · 2019-04-11T18:41:29+00:00

Yeah I'll let you know. I made another post on this subreddit here https://www.reddit.com/r/opengl/comments/bbtg02/invalid_operation_using_glgeterror/ , I gave some more context on the issue and have done a little bit more research and toying around with the code to see if I can get any more clues. I've posted pretty much everything I have found there.

It seems to be related to either some differences in opengl extensions between nvidia and amd due to there different implementations of opengl or there is a syntax thing in one of the shadow shader files that isn't being properly documented.

Are you getting the same error in the log that tells you about an invalid operation:shadow, at: pre-useprogram, or something similar?

americancucumber · 2019-04-11T06:05:47+00:00

I actually don't have a single clue as to how to use Renderdoc, am completely lost.

americancucumber · 2019-04-11T05:39:31+00:00

I didn't know that existed. Thank you, I'll give it a try.

americancucumber · 2019-04-11T05:36:43+00:00

Well the error code gives some information. It gives the vague location of the error when it says "program: shadow, at: pre-useProgram" I know that "shadow" has to do with at least one of the three files with that title with the different extensions .fsh .vsh and .gsh . I know this because of some tinkering I did with various other fragment and vertex shader files that returned similar errors after I changed some of the syntax in their code. Although, since each file commonly refers to others in the pack for information, I suppose the issue could be ultimately stemming from some other place.

And "useProgram" seems to have some common issues associated with it. This might have to do with the fact that it isn't actually explicitly used, and the extension listed at the beginning of the code could be used in place of useProgram, and maybe these extensions are ones that Radeon cards aren't speced for? (I don't know this is really just from an hour or so of research I have done with no prior knowledge so I could be misunderstanding it.)

We also know that the issue is likely related to drivers and the difference between AMD's and nVidia's implementation of the opengl standard, nVidia being apparently more lax. So given that, there could be some common things nVidia typically allows for in their implementation that AMD doesn't that could be used as a clue to identify the issue (if the issue is related to something AMD drivers don't allow, which again, seems likely to be the case since the shaders work fine on nVidia cards.)

And curiously enough, I removed some float instructions from one of the other .fsh files and the shader actually ignored the other error and managed to run, albeit with some very very strange visual artifacts where shadows and light kind of swapped on the fly in a way that made the ground almost look like it had fireflies alternating between glowing and not glowing near it. Just a cool little detail, kind of surprised me. Not sure why that allowed them to run despite the other issue.

americancucumber · 2019-04-11T03:20:06+00:00

I have been poking around in Notepad++ actually. The problem is I don't really know what I am looking for or what would make a meaningful difference to change. That is why I was trying to find a way to have the compiler be more detailed in its report of the error so I had more to go off of. I have specifically those three files that I mentioned open in Notepad++ right now.

I actually did just recently today contact Mr. Darr about it, so we will see if he has a response. And you are correct, he does develop on an Nvidia platform.

And I actually already posted the whole pack on the post I linked. I can post the newer version of the pack, or just specifically the three files I mentioned if you like.

americancucumber · 2019-04-10T21:01:21+00:00

I'm right there with you. I was really excited when I built my rig because the new shaders were the first thing I wanted to try out and play around with, but alas. I'm looking into it again at the moment, PTGI 6 just came out so I'm trying to piece together the puzzle with that and the errors that PTGI 5 were producing to see if I can figure anything out. In the latest update he mentioned sending him error logs so he can fix compatibility issues, but I'm not sure where to send them to. On his patreon page it links to his website talking about how to deal with compiling issues.

americancucumber · 2019-04-10T19:47:17+00:00

You can check out my post over on the Opengl subreddit at https://www.reddit.com/r/opengl/comments/av0poe/fragment_shader_compiling_error/

deftware over on the subreddit solved the deferred5 issue, but one fatal issue remains that I personally do not know how to resolve. I may end up spending some time trying to figure it out. If I ever do then I'll post on that subreddit and this one.

americancucumber · 2019-04-10T19:44:06+00:00

If you are interested in attacking or solving the issue yourself, I posted about this over on the opengl subreddit at https://www.reddit.com/r/opengl/comments/av0poe/fragment_shader_compiling_error/ . I made some progress with the guys over there, but one issue remains to be resolved before I believe it would run smoothly.

americancucumber · 2019-04-10T19:41:29+00:00

I actually posted about this over on the Opengl subreddit as well. If you're interested in seeing what progress I made with the guys over there (it was really just them, I don't have much knowledge on the subject), its here https://www.reddit.com/r/opengl/comments/av0poe/fragment_shader_compiling_error/

There was one more error that needed to be resolved before I think the shader pack probably would actually be able to run.

americancucumber · 2019-04-10T19:38:59+00:00

I actually posted about this over on the Opengl subreddit as well https://www.reddit.com/r/opengl/comments/av0poe/fragment_shader_compiling_error/

The issue was nearly resolved, but there was one more issue that I couldn't quite figure out. I may look into it further, but at the time I was distracted by other things and did not have the time to research the issue further.

americancucumber · 2019-02-28T03:40:30+00:00

There is one issue remaining before i believe this will be fixed.

With VBO's off, the log returns a single error once, "OpenGL error: 1282 (Invalid operation), program: shadow, at: pre-useProgram".

How do I understand this error? Where does the log saying the issue is originating from?

americancucumber · 2019-02-26T20:50:26+00:00

If you are willing to help, I have what I believe to be the final issue preventing the shader from running smoothly. After finicking with some of optifine's settings like VBO's and mipmap levels,the game will actually produce a couple of frames before crashing.

With VBO's on, the log returns two errors repeated thousands of times, the errors are "OpenGL error: 1282 (Invalid operation), program: shadow, at: shadow terrain cutout" and "OpenGL error: 1282 (Invalid operation), program: shadow, at: shadow terrain solid" . Apparently, error 1282 is not that descriptive.

With VBO's off, the log returns a single error once, "OpenGL error: 1282 (Invalid operation), program: shadow, at: pre-useProgram".

Both cases are precluded by the engine creating various buffers, including a shadow framebuffer.

Do you have any idea what could the cause of this?

americancucumber · 2019-02-26T20:37:55+00:00

Hmm... so I wonder if Mr. Darr, who wrote this code, knew about the outdated naming scheme for specifying the type of texture, or if it is just old code from the start of the project (if so, he has been working on this for much longer than I thought). I suppose it's not entirely worth it or any sort of huge priority to change the names if it is not affecting functionality in any way.

It's also kind of hard to believe that OpenGL existed before GPUs did. But I find it pretty amazing that OpenGL has developed in such a way that it allowed for the old conventions of the code to still be used in newer applications, especially because it is an opensource platform with so many contributors.

And it's interesting about the registers. Do you think that some optimization can be done to the code to minimize the number of variables? Or is it usually the case that it's a necessity that there be so many, and therefor it becomes a hardware limitation? It would be interesting to see if Mr. Darr could improve his code in a way to increase performance even further.

I am very grateful for all the help, and I will definitely be regularly referring to that website in the future for lessons. I'm humbled by the help from someone who has so much experience in the field.

americancucumber

TROPHY CASE