• entries
    422
  • comments
    1540
  • views
    488353

Book editing

Sign in to follow this  
jollyjeffers

88 views

Can I indirectly cover indirect light in my book?? [lol]

We got the technical review back on our initial 'finished' book manuscript. Proved to be an interesting read with a lot of valid points (no idea who reviewed it, but they know their stuff!). Now the proverbial ball is back in my court.

As I'm sure you'll all appreciate, the words I've written are my personal interpretation of a given set of technologies and theories and I will have under- or over- emphasised parts that I personally see as being more or less important. When someone else comes and reviews it, even if they are closely aligned to your views, are going to introduce their own 'personality' into the text. This is mostly a good thing as it forces you to see your work as someone else might, but ultimately it leads to the choice - Do I stick with the way I wanted to portray the topic, or do I change my thinking to be more like X's and change the text accordingly?

I'm inclined to lean towards changing to suit the audience because at the end of the day this book is for them to learn from, not me [smile]

But that said, I have one tough decision to make. Figured I'd write about it here in the interest of gathering your feedback as well as stopping my journal dropping off the bottom of the listing (!![oh]!!).


Ok, so I put a lot of emphasis on dynamic lighting - all of the applied chapters are about lighting models that can be done with no precomputation and are fully shader driven. Obviously this is a quite narrow viewpoint as fully static-lighting (e.g. radiosity) as well as hybrid (e.g. PRT/SH) are perfectly valid techniques in some real-time scenarios.

Early in my section I do make the mistake of arguing that "non-dynamic lighting is useless, avoid at all costs" as a way of supporting my decision to focus only on this subset throughout the remainder of the section.

I need to change this to be less black-and-white, but that's easy.

Our technical reviewer has basically suggested that I should include a couple of extra chapters on indirect lighting and other precomputed lighting techniques. I fully understand their logic and I agree with the few examples listed...

But in a nutshell, I don't think I want to add these chapters.
  1. We don't have much time before we go to print and launch. Editing is okay, adding it hard.
  2. Indirect lighting isn't my area of expertise. I've played with most of the major techniques over the years, but can't claim to be an expert.
  3. There isn't enough space to cover the techniques in as much detail as dynamic/direct lighting has received. Given that it's a big topic I'm wondering whether a half-assed glorified list of techniques is actually worth the extra page count? A list of "further reading" references might well be a more effective use of space..


So, What do you think?
Sign in to follow this  


7 Comments


Recommended Comments

I'd say it sounds like a bad idea to write about something with which you're not fully familiar. It's interesting that you can understand something well enough to use it, but the real test comes when you try to explain it to someone else - that's when you find out if you truly know your stuff.

You've also got a fair point that you don't want to write only a short and quick introduction, because that's not really a useful use of space. It won't tell people much more than a simple google search could, and having an introduction but no body is worse than nothing at all.

I'd say that the best solution is simply to make references in appropriate places to other non-dynamic techniques that would be useful - stepping stones for people to continue on reading in other places. No one book has to be the source of all information :).

Good luck with the rest of the process, don't tear out *too* much hair.

Share this comment


Link to comment
Don't add them. Indirect lighting is much more involved than direct lighting-- techniques like radiosity or PRT+SH require deep coverage. Definitely can't be added as an after-thought.

Share this comment


Link to comment
Thanks for the quick replies - good to hear that, so far, people agree with my assessment [grin]

Quote:
It's interesting that you can understand something well enough to use it, but the real test comes when you try to explain it to someone else - that's when you find out if you truly know your stuff.
Absolutely true! It's also a prime example of why a lot of "n00b's" who write tutorials often don't put together good content even though they think they understand the topic...


I'm currently draughting out my changes and I'm going to cover the basic definitions and why they should be of interest along with the names of a few techniques and how they relate to the bigger picture.

Share this comment


Link to comment
Quote:
Original post by Muhammad Haggag
Don't add them. Indirect lighting is much more involved than direct lighting-- techniques like radiosity or PRT+SH require deep coverage. Definitely can't be added as an after-thought.
I couldn't agree more! I think the incompleteness of those chapters would overshadow (EDIT: no pun intended...) the completeness of the direct section. Stay with what you know, which happens to include the information you just posted: that indirect is important, a huge topic, and that there are other resources out there for you to learn from.

Share this comment


Link to comment
A list of "further reading" references with a list of indirect lighting methods and descriptions wouldn't be that bad for completeness. You could be honest with your readers and explain why the chapter exists, in an indirect way of course.

I wrote this on NeXe a while back if it helps. http://nexe.gamedev.net/directKnowledge/default.asp?p=Precomputed%20Radiance%20Transfer

Share this comment


Link to comment
I would say to have a single chapter overview or a chapter section to at least explain what some of the options are.

Ideally everything is done dynamically, but the speed hit is often not worth it for the increase in visual quality. For instance, as much time as I've spent over the years on shadow techniques, I should have skipped them in my current engine.

More and more I'm adding non-shadowing mood lights to my levels, to accentuate something or to add some contrast. Ideally these would all be burned into a single lightmap.

You could discuss various ways to cache lighting terms. Occlusion maps, storing light vectors per texel or per-vertex, storing SH terms.

Another important area is having your static object lighting match your dynamic lighted objects. Irradiance volumes of one sort or another are a good method here.

Share this comment


Link to comment
Thanks for the info noaktree and SimmerD [smile]

Quote:
I would say to have a single chapter overview or a chapter section to at least explain what some of the options are.
I currently have 3-4 printed pages within the first chapter explaining why the reader should care about the difference, what the difference is and how they might go about further reading.

Quote:
Ideally everything is done dynamically, but the speed hit is often not worth it for the increase in visual quality. For instance, as much time as I've spent over the years on shadow techniques, I should have skipped them in my current engine.
Makes sense to me and echoes what I've heard from the other people I've talked about it with. Dynamic would be preferred but realistically we still need to "hack" our way around things...

Quote:
You could discuss various ways to cache lighting terms. Occlusion maps, storing light vectors per texel or per-vertex, storing SH terms.

Another important area is having your static object lighting match your dynamic lighted objects. Irradiance volumes of one sort or another are a good method here.
Very good suggestions - thanks.

I think I'll continue editing my section as though I wasn't adding anything new on indirect/global illumination, but if the deadlines permit I'll sneak in a chapter of new material covering the implementation side. The reader can then go and research the actual algorithm theory and match that up to the standard features exposed in the API...

Cheers,
Jack

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now