DICE PACKS BUNDLE
Page 4 of 4 First ... 234
  1. #31
    Quote Originally Posted by johnecc View Post
    Are we forgetting that this is a representation of a tabletop role playing environment to allow us to play a game remotely? When was the last time you had coloured lights in a face to face game?

    Yes it is nice to have, but do we really need to be arguing about industry standards that are probably for film or video games (not sure because I haven’t read them, nor have a desire to).

    Just my opinion. I think Carl and Smiteworks have done outstanding work getting us what we have.
    Literally last night. PCs manipulated some arcane machinery. Altar changed from glowing purple to glowing yellow. I hit 1 button on the stream deck and all the DMX lights (except the pin spots on the dice trays) shifted smoothly from purple to yellow... and the players smiled and said 'woah. cool.'

    I didn't bother changing the light on the map, as there would have been no discernable difference under the current implementation.

  2. #32
    Quote Originally Posted by HywelPhillips View Post
    Umm, I wasn't arguing, I was trying to help, and to understand the issues. I am also relatively happy with the solution as it stands presently - I've not made any noise about it since the last round of threads several years ago when lighting first came out.

    FGU is literally built using a video game engine, and the problem we're discussing (colour channels clipping to white in an unattractive way) is a long-standing issue in the both the video game and the film industry. I happen to be a physicist-turned-cinematographer, I was just pointing out that this particular problem - the rendering of overlapping coloured lights in the presence of super-white values above the nominal white point of 255,255,255 has been solved. I know about that solution from my day job, and I was just trying to point out some resources that exist within the framework that FGU is developed in that might help if a more comprehensive solution to this rendering problem is required.

    I'm absolutely happy with Carl's decision not to go down the road of that solution because it's not suitable for the requirements of FGU as a VTT, and I was just trying to understand exactly what those issues are in my last reply. (Because physicist and therefore curious).

    For my own games I still use the formula I recommended people to use a couple of years ago, which I'll restate here for completeness:



    For general use where you just want to know if the character can see or not, sticking with FGU defaults for lights won't send you far wrong, although you will have some unphysical artefacts where lights overlap that will look weird to some. Carl's new shading procedure looks like a worthwhile improvement without going to the full solution of working in a different colour space, which he has explained they're not going to adopt.

    If you want to make an impressive cinematic scene with coloured lights in FGU today, stick to my advice quoted above and tone any lights carried by the characters down to alpha 200 or so, avoid overlapping the coloured lights on the map, and you'll get a perfectly serviceable and atmospheric result, which Carl's optional rendering mode should improve still further.

    Cheers, Hywel
    Everything you have contributed here has been utterly fascinating. Thank you so much for the detailed explanations!

    I do think the current proposed change will be a "good enough" improvement that is vastly better than it is now, and I suspect using some of your tips above, I will start exploring using colored lights again.

  3. #33
    Quote Originally Posted by Zacchaeus View Post
    Some in depth discussion on the technicalities of lighting here https://www.fantasygrounds.com/forum...oves-the-color

    And, no it isn't a bug. It's meant to be that way since that's how it's programmed.
    It is a 'usability' bug. Programming only serves one purpose: meeting customer needs. If a programmed feature doesn't work for users then it can be considered as a bug. That's what happens in my company which is major software company. While I understand your point I beg to disagree with you.

  4. #34
    My goal in posting has been met by Carl's solution. The only concern I have is that of lights defined - dim or bright - can be lost completely. Its a relatively simple thing to make this, as Carl has shown, so that it can be no longer an issue.

    Cameras, video = trying to mimic realism. Can be expensive in processing/gpu to this in certain fixed environments - which FGU is.

    Realism is not a game.

    My post is to address purely game issues. I'm sure there a numerous solutions (as in most coding) to approach the problem, but I don't want to get lost in "they gave us and inch, lets see if we can take a mile" as I was very familiar with this in my coding days and even today in my extension coding days. I'm ruthless in maintaining "good enough".

    The solution carl has shown is "good enough" - if he wishes to do more that's up to him. But based on performance etc. - and what he has told us - this solution is "good enough".

    I'll take the inch.

    Others can battle for a mile.

    Looking forward to seeing faery fire and other effects in all types of lighting (unless they are the same of course) in FGU.
    Free(Forums/Forge) Extension(FGU 5E):
    Paid (Forge) Extension(FGU 5E):

  5. #35
    Quote Originally Posted by SilentRuin View Post
    My goal in posting has been met by Carl's solution. The only concern I have is that of lights defined - dim or bright - can be lost completely. Its a relatively simple thing to make this, as Carl has shown, so that it can be no longer an issue.

    Cameras, video = trying to mimic realism. Can be expensive in processing/gpu to this in certain fixed environments - which FGU is.

    Realism is not a game.

    My post is to address purely game issues. I'm sure there a numerous solutions (as in most coding) to approach the problem, but I don't want to get lost in "they gave us and inch, lets see if we can take a mile" as I was very familiar with this in my coding days and even today in my extension coding days. I'm ruthless in maintaining "good enough".

    The solution carl has shown is "good enough" - if he wishes to do more that's up to him. But based on performance etc. - and what he has told us - this solution is "good enough".

    I'll take the inch.

    Others can battle for a mile.

    Looking forward to seeing faery fire and other effects in all types of lighting (unless they are the same of course) in FGU.
    Well said.

  6. #36
    Quote Originally Posted by pindercarl View Post
    I appreciate the input. I think I've addressed why we won't be applying any post-processing to the lighting. Thanks again.
    Any idea when we might see this change? I thought maybe this last Tuesday update but was not to be
    Free(Forums/Forge) Extension(FGU 5E):
    Paid (Forge) Extension(FGU 5E):

  7. #37
    When the testing of the changes is finished. We don't want to introduce any new issues with the changes.
    Dominic Morta
    Ruleset Developer
    Smiteworks

    How to zip up your campaign if the Developers ask for it-How to zip up your campaign if the Developers ask for it

    How to provide an Unity Connection issue?-Connection Issues and What to Provide

    Unity Updater issue?-Updater Issues

    Classic and Unity Port Forwarding?-Fantasy Grounds Connections Explained

    Comcast or Cox ISP User?-Comcast XFinity and Cox Users

    Have a suggestion?-Feature Request

  8. #38
    Very reasonable. I only asked as once again my players got in a session with Rhime of the Frostmaiden in the Jarlsmoot map and lit 6 braziers - of which you could not see one of the colors as they were all wiped out by a lantern (and the white light among the braziers).
    Free(Forums/Forge) Extension(FGU 5E):
    Paid (Forge) Extension(FGU 5E):

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
STAR TREK 2d20

Log in

Log in