[Person of Color]

TerminX, on 17 November 2015 - 01:53 PM, said:

Polymer might run like a crippled bag of dicks, but spontaneous reboots are a hardware or driver problem, every time. 100%. I think this is more of a daily reminder that you should back off on your overclocks until you figure out what the fuck you're doing.

She's running bone stock. If someone needs more performance than an R9 290 can deliver they need to go outside and inhale the fresh scent of pussy. I'm serious, who the fuck needs more than that? Does your fake realism need to look 3% less fake?

Furthermore - implying runaway framerates have never been an issue before...You should have heard the coil whine when I turned off vsync, this poor girl was under hella load. It usually sounds like that playing the new UT or something.

http://www.bit-tech....it-framerates/1

inb4 "bad video card," most R9 290's have audible VRM's. And this wasn't bad video card loud, just noticeable.

But I guess my hardware is the issue right? PROTIP: It's a shitty renderer.

MusicallyInspired, on 17 November 2015 - 04:11 PM, said:

Polymer works just fine on my system and I haven't seen any model disappearing issues yet. Whenever I play Duke it's with Polymer only.

You're the one who bought a Radeon card against all warnings and recommendations. But you said you didn't care...I guess you care now?

I still don't care. It's not my problem. I can always just connect a laptop to my monitor if it's that big of a deal.

Tea Monster, on 17 November 2015 - 04:59 PM, said:

I understand that people have jobs and real lives and so forth. Thats great. But the model rendering issue has been requested for years and years now and nobody has even replied to the request or addressed it as an issue in that time. Instead of "Sorry, kinda busy" or even "No can do, too much on" its either Hendricks standard "Dis gon B Gud" gif, and now Plagman has replied with... well, I'm not going to repeat it.

Respect needs to operate in both directions.

^^^ This. It's shitty code and the developers attitude is shittier.

icecoldduke, on 17 November 2015 - 08:39 PM, said:

I am working on fixing up Polymer. To say the polymer rendering pipeline is not optimized for performance is a gross understatement. The renderer stalls in a bunch of places because of bad design. This isn't to say anything bad about Plagman, he got it working and that is a huge undertaking.

You get poor performance with Polymer because of :
1) Hardware occlusion queries, the GPU will stall while waiting for the previous frames "Is object X" visible requests to come back. I am working on re-creating my software occlusion query system, this system will work in another thread and will greatly improve performance.
2) The renderer is doing matrix math via the driver. I have re-created my matrix math class to replace this functionality. This is less of a performance issue as it is very nasty.
3) Hardware State Changes - this hinders wavefront batching, this has been slightly fixed with Plagman's "bucket" system but there is still work to be done there.

The poor performance everyone is getting out of Polymer isn't because of your hardware, simply put Polymer is GPU/Driver bound because of it's design, not because of the complexity of what it has to render.



Using vsync is the proper way to fix screen tearing. How vsync works is the GPU waits to flip buffers until vblank is complete. This can't be emulated with any other method. If vsync is slow for you, get a better monitor .

First off, thanks for your initiative. I really mean it. Start a Patreon if this turns into too much work, I think you'd be surprised how many people will help you out.

Second off, I love how someone comes in and backs up what I'm saying. It's shitty code, plain and simple. Although I will add that mouse lag isn't usually monitor related, I can throw in my old GTX 770 and have none of these issues.

Nevander, on 18 November 2015 - 08:20 AM, said:

I wish I could but my cellphone is a potato. There was a video I saw before that accurately showed what my problem is. Let me see if I can relocate it.

EDIT: Found 'em. Mine is IDENTICAL to the second video.
Source: https://forums.duke4...tteringhitching

Hey, those are mine! Yeah I took those with my old Radeon 6970. The R9 290 behaves differently.

[Forge]

[Mblackwell]

Uh, I'm running a scene with lights right now that's 400fps just to be sure and my GTX 970 SSC (so overclocked) is maintaining 60C with the fan only at 450rpm, and a quick test at 700fps and I only needed 650rpm to maintain that temp.

So if your card is so loud and so hot that it crashes when under load then either you're giving it a ridiculous load and should cap fps (which is possible in EDuke32 for all renderers), or the card has a serious flaw.

[Nevander]

Person of Color, on 20 November 2015 - 11:00 PM, said:

Hey, those are mine! Yeah I took those with my old Radeon 6970. The R9 290 behaves differently.

Huh. I'm on an R9 270X and I get those issues exactly like you did on that card. Did AMD change something drastically between these two cards?

[icecoldduke]

Nevander, on 21 November 2015 - 01:02 AM, said:

Huh. I'm on an R9 270X and I get those issues exactly like you did on that card. Did AMD change something drastically between these two cards?

For the best performance with any game, you really should be using NVIDIA hardware. It is worth the extra $100-$150.

Quote

So if your card is so loud and so hot that it crashes when under load then either you're giving it a ridiculous load and should cap fps (which is possible in EDuke32 for all renderers), or the card has a serious flaw.

Polymer wouldn't cause over-heating. In polymer the GPU is starved for work during low FPS cases, if the GPU isn't overloaded then it wouldn't be causing your heating issues.

[Jimmy]

Tea Monster, on 18 November 2015 - 10:58 PM, said:

There is a deep-seated anti-HRP sentiment in the community, and that seems to have coupled with the Polymer isssues into a dislike of anything that dosen't conform to the original render style. Out of the whole community, I think there are only 3 or 4 who still use Polymer. I've been out of the loop for a while, but I think it's only Roma Loom and Spiker who still make content for the HRP. We used to have a thriving modelling community - it's pretty much all either disappeared or dropped off the radar.

There is an active Doom modelling community. It's not just the old stuff any more either. There are a number of people developing new content.. The new render engine for Doomsday is currently under active development.

Any "anti-HRP" sentiment has to do with the fact that the HRP is of a poor quality overall, with varying styles and qualities mish-mashed together haphazardly, and the fact it's in an unfinished state and as a mod, it's just an asset replacement. There is no internal modifications that make the game actually use the assets to make the game look better. It's like spray painting a turd gold, sure, its gold but its still just shit. And Polymer is pretty great visually, if someone would fix the shit coding I guarantee you it'd become more commonly used than classic or Polymost.

[Plagman]

I get that it's frustrating to get something that only works half as well as you want it to.

Understand the BUILD engine was quite unlike other contemporary realtime engines. It was these other technologies that went on to set the standard that shaped 3D hardware. Ken had to write Polymost himself after seeing nobody step up for a good reason: it's because it wasn't entirely trivial to do so. Even though Polymer was still a huge compromise in terms of fully supporting what BUILD could do and rendered incorrectly in a bunch of cases, it was still pretty unefficient despite quite a bit of work having been put into it. Doom and Quake had a very deliberate separation of the static map geometry and dynamic entities ingrained into their data structures, and everyone went to follow on along that model. BUILD had no such thing, and is frankly a pain to deal with in all the possible scenarios you can set it up. There's always something that you can't quite get right, and trying to write a renderer from scratch that will accomodate all its crazy needs, while still maintaining appropriate speeds, while not being a pile of hacks catering to particular pieces of content, was just way more work than I could afford to carve out from my free time. All the APIs and accelerator HW were relatively rigid in the scenarios they supported and they all followed the needs of that other dominating engine trend. It's only relatively recently that accelerator hardware became programmable enough to easily cater for these sort of needs without requiring a whole lot of extra optimization work.

You didn't see a lot of direct fallout from that because the version that got released had undergone enough whack-a-mole coding sessions that the official Duke3D episodes and a lot of the popular user maps would render mostly accurately, but there was still always something that would break it in some way.

Bottomline is, I worked on that stuff because Duke3D is a game I was very fond of and thought it would be cool. Despite the frustration and sleepless nights and literally years working on scrapped experiments, I had tons of fun working through these things and eventually releasing something that actually sort of worked. On top of that, people were also running it and having fun too! How cool is that, people finding that what you thought was awesome is also awesome and your work ending up fun for them too?

To the people that think it's cool too and just wish it was better than it is currently, I say: so do I, and I also hope it'll eventually come to happen, be it through me or someone else. To the people that, in addition to the above, act like spoiled toddlers and throw tantrums at the very same persons that helped them get that far to begin with: go choke on a whole bucket of shit.

[icecoldduke]

Quote

To the people that think it's cool too and just wish it was better than it is currently, I say: so do I, and I also hope it'll eventually come to happen, be it through me or someone else. To the people that, in addition to the above, act like spoiled toddlers and throw tantrums at the very same persons that helped them get that far to begin with: go choke on a whole bucket of shit.

People unfortunately only see the end result of a product, and not all the technical stuff's that went into making it. They can't even differentiate between what are engine issues, and what is a driver issue(case and point Nevander). You have worked in the game industry longer then me, and have shipped more titles then me...people knock on things basisly all the time. Once in awhile though they hit you with something tangible, even if they express there position poorly.

I have begun work on what I'm calling "Polymer NG", which is a total refactor of Polymer, and I would love it, if you have some time, to help me out with it. You did a great job on Polymer, anyone who thinks otherwise is an idiot. Unfortunately end users tend to be idiots, and only care about the final result. If anyone else is an engineer on here with rendering experience, I would love any additional help.

Reasons for heavy refactoring:

• Polymer conforms to build engine code standards, needs to be redone with OOP for performance, code readability, and code maintenance.
  
• Fixed function pipeline, needs to be deprecated. This will help with driver bottlenecks and enable debugging via NSIGHT.

What I've already done:

• Created the new PolymerNG renderer - currently doesn't render anything yet.
  
• Created a RHI layer, so the renderer is API agnostic.
  
• Created external shader support that uses HLSL syntax and converts to GLSL. Also have smart shader functionality(e.g. automatic shader paremetor hookup).
  
• Math Support Functions(Vector, Matrix, etc).

What needs to be done:

• Deprecation of fixed function code that Polymer relies on in Polymost.
  
• Getting the Albedo pass on its feet, including the software occlusion system.
  
• Get deffered lighting system in.
  
• Shadow Mapping: We can already use what's in polymer already, but there are some things missing I'd like to get in.

What would be nice:

• Volumetric Light Scattering(Realtime God Rays) -- see below.
  
• Screen Space Reflection
  
• Tone Mapping
  
• Two specular map support
  
• G-Buffer
  
• Depth Of Field
  
• Subsurface Scattering.
  
• SSAO

BackLog:

• Phsyics
  
• Skeletal Models - FBX

I added Volumetric Light Scattering(Realtime God Rays) to Unreal 4, I plan on moving my code over to PolymerNG. This really isn't backlogged, since it should only take a day or so to copy my code over to eduke32.


As you can see, there is quite a lot of work that needs to be done, to truely get a next-gen renderer working.

[MetHy]

I've heard another person (not the first) claiming he can't even play eDuke32 in classic renderer because recent (it's been like that for at least a year though) versions lag too much.

I think that's more important at the moment than laggy polymer.

People complaining about classic renderer lagging surely don't have recent computers, but still, it shouldn't take a high end computer to play DN3D in 8bit.
All the optional new fancy stuff shouldn't be at the detriment of the classic game imo.

[Nevander]

icecoldduke, on 23 November 2015 - 07:11 AM, said:

They can't even differentiate between what are engine issues, and what is a driver issue(case and point Nevander).

To be fair, in the past I've had problems with things and updating my drivers did absolutely nothing to help the issue. A lot of times I feel it's not any one piece of my hardware or my drivers, and it's that perfect combination of all my hardware together that decides to give me the problem that many others do not get. I DO understand the difference, but how can I tell? You said so yourself the end user only sees the product. If I were involved in the development, I'd be able to tell that difference right away because I'd know the insides of the coding and renderer. My point is, please also try to understand the end user's side too. We aren't all engine coding inclined and might not be able to understand it, so when we see issues like this, we have no choice.

And to Plagman, I honestly do appreciate your work. I'm sure everyone really does, even the OP. It's not easy I'm sure. We all do thank you for the work you've put in and making Duke 3D look and play better than ever on modern systems with modern rendering. But like you said, it does get frustrating for the end users when they expect something to work and it doesn't work as they'd hoped or seen advertised. It's like in my case, my PC should more than handle Polymer, but it doesn't. This would clearly upset anyone who wants to enjoy it but can't due to things being unoptimized, when that's not even mentioned on the package. I'm referring to the main EDuke site that says Polymer "requires a bad-ass video card." True it does, but it also requires a lot more than that, with most of it not even being on the user's end. I understand you want to "sell" people into wanting to use Polymer, and saying something like "it's not optimized and will run poorly" might force people away, but they are reminded that it's not required at all and there's two other ways to play the game. I think most people who go to use EDuke32 now do so because they see Polymer and then end up being disappointed. I guess what I'm trying to say is that such a feature as Polymer might not want to be advertised as much until it's in such a stage that you and many others want to see it in.

Either way, Polymer and what it does and can do in the future is awesome, and you are awesome for making it happen.

[icecoldduke]

MetHy, on 23 November 2015 - 07:26 AM, said:

People complaining about classic renderer lagging surely don't have recent computers, but still, it shouldn't take a high end computer to play DN3D in 8bit.

In my recent benchmarks the engine isn't CPU bound. If someone who is having slowdowns in the classic renderer, could compile and run from Visual Studio, with the performance stuff turned on, and post there results that would help people isolate the problem.

I simply can't repo the slow downs in the classic renderer, but I am running a i7. I don't have any plans though on touching the classic renderer.

[Hendricks266]

MetHy, on 23 November 2015 - 07:26 AM, said:

I've heard another person (not the first) claiming he can't even play eDuke32 in classic renderer because recent (it's been like that for at least a year though) versions lag too much.

This is the first I've heard of this. If said person wants to see any difference, instead of shitposting they should get off their ass and report it. I have two ideas about what could be causing this but there is no way for me to know because I don't have the problem.

Compare revisions 4080 and 4253 and the ones prior to them.

Circle one for each revision.
Does this revision have the slowdown?
4079: Y/N
4080: Y/N
4252: Y/N
4253: Y/N

[blizzart]

Hendricks266, on 23 November 2015 - 07:42 AM, said:

This is the first I've heard of this. If said person wants to see any difference, instead of shitposting they should get off their ass and report it. I have two ideas about what could be causing this but there is no way for me to know because I don't have the problem.

Compare revisions 4080 and 4253 and the ones prior to them.

Circle one for each revision.
Does this revision have the slowdown?
4079: Y/N
4080: Y/N
4252: Y/N
4253: Y/N

Actually I have slowdown in classic renderer here and there for about half a year now (even with actual builds). It always happens in large outdoor areas where the game suddenly starts to lag. It´s not the fps but the time of screen refreshing turns up to over 40ms at times. I always thought the problem is related to my end, so I never asked for it before.

Maybe that can help you.

[blizzart]

icecoldduke, on 23 November 2015 - 07:11 AM, said:

People unfortunately only see the end result of a product, and not all the technical stuff's that went into making it. They can't even differentiate between what are engine issues, and what is a driver issue(case and point Nevander). You have worked in the game industry longer then me, and have shipped more titles then me...people knock on things basisly all the time. Once in awhile though they hit you with something tangible, even if they express there position poorly.

I have begun work on what I'm calling "Polymer NG", which is a total refactor of Polymer, and I would love it, if you have some time, to help me out with it. You did a great job on Polymer, anyone who thinks otherwise is an idiot. Unfortunately end users tend to be idiots, and only care about the final result. If anyone else is an engineer on here with rendering experience, I would love any additional help.

Reasons for heavy refactoring:

• Polymer conforms to build engine code standards, needs to be redone with OOP for performance, code readability, and code maintenance.
  
• Fixed function pipeline, needs to be deprecated. This will help with driver bottlenecks and enable debugging via NSIGHT.

What I've already done:

• Created the new PolymerNG renderer - currently doesn't render anything yet.
  
• Created a RHI layer, so the renderer is API agnostic.
  
• Created external shader support that uses HLSL syntax and converts to GLSL. Also have smart shader functionality(e.g. automatic shader paremetor hookup).
  
• Math Support Functions(Vector, Matrix, etc).

What needs to be done:

• Deprecation of fixed function code that Polymer relies on in Polymost.
  
• Getting the Albedo pass on its feet, including the software occlusion system.
  
• Get deffered lighting system in.
  
• Shadow Mapping: We can already use what's in polymer already, but there are some things missing I'd like to get in.

What would be nice:

• Volumetric Light Scattering(Realtime God Rays) -- see below.
  
• Screen Space Reflection
  
• Tone Mapping
  
• Two specular map support
  
• G-Buffer
  
• Depth Of Field
  
• Subsurface Scattering.

BackLog:

• Phsyics
  
• Skeletal Models - FBX

I added Volumetric Light Scattering(Realtime God Rays) to Unreal 4, I plan on moving my code over to PolymerNG. This really isn't backlogged, since it should only take a day or so to copy my code over to eduke32.


As you can see, there is quite a lot of work that needs to be done, to truely get a next-gen renderer working.

I really like what you posted there icecoldduke. God rays would be a great thing. Right now I use "ray sprites" to simulate that effect in my polymer mod.

Sadly I don´t have any experience with all that technical stuff but I can offer you some testing with the "new" renderer, if you looking for someone here at any point of development.

[icecoldduke]

blizzart, on 23 November 2015 - 08:23 AM, said:

I really like what you posted there icecoldduke. God rays would be a great thing. Right now I use "ray sprites" to simulate that effect in my polymer mod.

Sadly I don´t have any experience with all that technical stuff but I can offer you some testing with the "new" renderer, if you looking for someone here at any point of development.

VLS is a expensive effect, realistically in a scene it will take up 2ms or more per VLS light in the scene(to hold 60fps we need to be at or under 16ms). VLS should be used in areas that have big occluders, dynamically effecting the rays. Such as a fan, a big boss, or lots of enemies. VLS should NOT replace "ray sprites" in areas that would not have dynamic occluders going through the rays(such as a ray going through a Window), while VLS can handle such a situation, it is a waste of performance.

[blizzart]

icecoldduke, on 23 November 2015 - 08:37 AM, said:

VLS is a expensive effect, realistically in a scene it will take up 2ms or more per VLS light in the scene(to hold 60fps we need to be at or under 16ms). VLS should be used in areas that have big occluders, dynamically effecting the rays. Such as a fan, a big boss, or lots of enemies. VLS should NOT replace "ray sprites" in areas that would not have dynamic occluders going through the rays(such as a ray going through a Window), while VLS can handle such a situation, it is a waste of performance.

Yeah, dynamic scenes was what I was aiming for. I agree with you, that static scenes could use sprite rays instead. Though I don´t have any clue of how resource intense this is, it was more out of laziness (create & editing the sprite and place it in the map ).

[MusicallyInspired]

Maybe if everyone was a little more supportive of polymer and plagman's efforts instead of complaining about it all the time, he might have actually had some inspiration and motivation to work on it. As it stands, there's a reason why it seems like everyone has an anti-polymer attitude because all we ever hear are negative things about the crap job the devs are doing. I wouldn't want to work on it either with that aura of ungratefulness. Remember when there was a bug report system and all our issues were being sort of resolved? We've gone from that to nothing probably because of all the hatred.

I'll say it again, I love polymer and play Duke exclusively with it for the most part. I had more problems than anybody with polymer when I had my older Radeon card, but I still enjoyed it. Now that I run Nvidia, it's even better and I'm saddened that there hasn't been more effort to flesh it out due to the backlash. I certainly appreciate your work, plagman, even if you never touch it again. Thanks for looking specifically into my problems way back then. And thank you, icecoldduke, for attempting to pick up the reigns. I hope you can do great things with it.

[Mblackwell]

Meh, the only fancy effect I give a shit about is SSAO. Which is NOT on that list.

Why HLSL -> GLSL? Why not just GLSL from the beginning? Depending on your setup there can be quite a few inefficiencies that crop up that way iirc (but it's been awhile since I messed around with/researched shaders).

[icecoldduke]

MusicallyInspired, on 23 November 2015 - 08:52 AM, said:

Maybe if everyone was a little more supportive of polymer and plagman's efforts instead of complaining about it all the time, he might have actually had some inspiration and motivation to work on it. As it stands, there's a reason why it seems like everyone has an anti-polymer attitude because all we ever hear are negative things about the crap job the devs are doing. I wouldn't want to work on it either with that aura of ungratefulness. Remember when there was a bug report system and all our issues were being sort of resolved? We've gone from that to nothing probably because of all the hatred.

I'll say it again, I love polymer and play Duke exclusively with it for the most part. I had more problems than anybody with polymer when I had my older Radeon card, but I still enjoyed it. Now that I run Nvidia, it's even better and I'm saddened that there hasn't been more effort to flesh it out due to the backlash. I certainly appreciate your work, plagman, even if you never touch it again. Thanks for looking specifically into my problems way back then. And thank you, icecoldduke, for attempting to pick up the reigns. I hope you can do great things with it.

I'm anticipating the shit fest to come raining down on me when I start releasing builds. . I'm hoping Plagman joins the NG effort, I can't emphasize enough how great of a engineer he is.

Mblackwell, on 23 November 2015 - 08:57 AM, said:

Meh, the only fancy effect I give a shit about is SSAO. Which is NOT on that list.

Why HLSL -> GLSL? Why not just GLSL from the beginning? Depending on your setup there can be quite a few inefficiencies that crop up that way iirc (but it's been awhile since I messed around with/researched shaders).

Added SSAO .

I prefer the syntax of HLSL personally, compared to GLSL. The conversion system is a abstraction layer above the api specific shader language. This allows for shader conversion to different launguages. So we only have one shader for all API's. This for example would allow for D3D11 support, without shader modification.

I think your thinking of Nvidia CG which I am not using.

[Inspector Lagomorf]

Hendricks266, on 23 November 2015 - 07:42 AM, said:

This is the first I've heard of this. If said person wants to see any difference, instead of shitposting they should get off their ass and report it.

You know that's not how things get done around here.

... Oh wait. It kind of is. You're right.

Speaking of, I haven't experienced any slowdown with the classic render and I use it all the time. But then again I use NVIDIA cards.

[Spiker]

Just to let you know. I've joined the forums like 8 years ago and for all this time I have been having a blast with Eduke32 and Polymer. I know it has it's flaws but it never spoiled the fun for me. What's more every improvement of the engine was making me feel like a kid who got his birthday present. I'm just a little bit busy since I got a new job but I still love the project and follow it with anticipation and joy

I've learnt a lot of cool stuff thanks to this project and I bet it's not over yet.

[Hendricks266]

It's official: As of five minutes ago (when it opened up to my major), I'm signed up to take a class in OpenGL graphics programming next semester.

[Mblackwell]

icecoldduke, on 23 November 2015 - 08:59 AM, said:

I prefer the syntax of HLSL personally, compared to GLSL. The conversion system is a abstraction layer above the api specific shader language. This allows for shader conversion to different launguages. So we only have one shader for all API's. This for example would allow for D3D11 support, without shader modification.

I think your thinking of Nvidia CG which I am not using.

Well, I was also thinking that if you're converting directly there tends to be trimming of HLSL code in places where GLSL could have used the information to tell the driver to move to fast paths. Have you seen SPIR-V?

[icecoldduke]

Mblackwell, on 23 November 2015 - 09:18 AM, said:

Well, I was also thinking that if you're converting directly there tends to be trimming of HLSL code in places where GLSL could have used the information to tell the driver to move to fast paths. Have you seen SPIR-V?

I have not looked into SPIR-V, I was aware of a bunch of different libraries that use LLVM to compile shaders down to various different languages. I even saw one that added OOP into shaders(which I thought was overkill). I'll look into SPIR-V more, it might be the right way to go. I will still need some of the preprocess steps I have in my code, such as automatic shader variable binding.

EDIT:

Yeah SPIR-V looks like something worth while to pursue.

Quote

It's official: As of five minutes ago (when it opened up to my major), I'm signed up to take a class in OpenGL graphics programming next semester.

I hope they teach you how to be a graphics engineer, not just how to code in OpenGL. .

[Mark]

All of this Polymer talk is making me tingly inside. Just be sure to use an svn or multiple backups. I'll cry a river of tears if I hear of a HD failure a couple of months from now.

[icecoldduke]

Mark., on 23 November 2015 - 01:57 PM, said:

All of this Polymer talk is making me tingly inside. Just be sure to use an svn or multiple backups. I'll cry a river of tears if I hear of a HD failure a couple of months from now.

I'm using Perforce.

[Micky C]

Mblackwell, on 23 November 2015 - 08:57 AM, said:

Meh, the only fancy effect I give a shit about is SSAO. Which is NOT on that list.

Sounds like someone's been reading my signature Is there any chance of getting global illumination included and bloom included? The former should go a long way towards definition and realism in maps.

Btw I'm curious, what does the NG stand for?

[icecoldduke]

Micky C, on 23 November 2015 - 03:18 PM, said:

Sounds like someone's been reading my signature Is there any chance of getting global illumination included and bloom included? The former should go a long way towards definition and realism in maps.

Btw I'm curious, what does the NG stand for?

NG = Next gen

HDR/Bloom yes.
Global Illumination no, a good enviro lighter can fake GI, its not worth the time to implement it, and I already have a full plate.

[LeoD]

Micky C, on 23 November 2015 - 03:18 PM, said:

Btw I'm curious, what does the NG stand for?

- Next Generation
- New Gadgets
- Nerds Galore

[Micky C]

icecoldduke, on 23 November 2015 - 03:21 PM, said:

NG = Next gen

HDR/Bloom yes.
Global Illumination no, a good enviro lighter can fake GI, its not worth the time to implement it, and I already have a full plate.

Yeah I wasn't so much thinking about the transferal of colour as I was about areas of maps without direct lighting looking dull. Sounds like it'll do the trick quite well