Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 12 Mar 2003
Offline Last Active May 24 2016 04:14 AM

#5113741 making a program, all code in one file

Posted by on 02 December 2013 - 07:33 AM

Which are the advantages of a giant single room apartment over a more traditional one? Sure, you gain some space (no walls), but you loose privacy, rational furnishing, comfort ... biggrin.png


Honestly, I don't see any real reason to write a (non trivial) application in a single file (I'm scared by the maintainance nightmare I would eventually address)

#5044174 What language do I use?

Posted by on 18 March 2013 - 05:07 AM

Well, they could tell you which is the language (mostly) used to build core engines of games such as Crysis and the like. But as already said, that info will not make you a better coder, not will make you write your first games (which is something far more important).

#5041149 OpenGL or DirectX

Posted by on 09 March 2013 - 06:21 AM

One of the people assisting me with the game is insisting I use OpenGL, saying that slowly it's going to replace DirectX.  And that it's "The graphics library of the future". I just don't know if I can believe him.


Is it possible that he refers to the recent projects of Valve in regards with linux? Valve is currently trying to lead a move of the game industry towards linux, and this means that those developers willing to follow them have to use OGL. Is not yet clear whether or not that shift will happen...

#4925572 Path Tracing BSDF

Posted by on 27 March 2012 - 02:05 AM

I must say that you have indeed beatiful renders, wich would deserve more complex scenes (i.e. Sponza Atrium).

If you have troubles with kd-trees and the like, try with something easier: BIH (Bounding interval hierarchy) is not as fast as kd-tree with SAH, but estimates suggest it is 60/70% its speed, so it may help you a lot, and is not so hard to implement (I did it as well, but I would rather not give you my implementation as for some reason it is really slow :-(

You can find the paper by googling and the ompf.org forum used to have several threads on that topic, with many implementations discussed (included my own). Now the ompf.org domain no longer points to the forum, but a (temporary?) replacement has been opened. I don't know if those threads have been moved, but if you ask them they will help you.

how should I go about simulating subsurface scattering (which is needed for realistic metal materials)

Honestly this is the first time I hear someone willing to implement SSS for metals (instead than skin, milk or marble)

Posted Image

And you could consider buying the "Physically based Raytracing: from theory to implementation": I have the first edition and it is truly amazing. In the second (IIRC) the show how to implement both BVH and SSS.
If you are interested in Raytracing/GI you should buy that book.

Hope this helps

#4923554 Java or C++?

Posted by on 20 March 2012 - 01:36 AM

If you want to target C++, then IMHO you should just decide between Java and C#. Python is nice and easy, but is too different (different syntax, different compilation model ...)

Usually this is not a problem at all, but if you want something that simplifies your path toward c++, then C# or Java.

And among these two, I would suggest Java: C# is a very beatiful language, but too much bound to Visual Studio: you could miss important steps performed by its features under the hood.
I suggest Java (notepad++ + javac at first) and then try NetBeans or Eclipse.

Mind you, that's just my opinion: if you pick C# instead that will work nonetheless.

#4910882 C First?

Posted by on 08 February 2012 - 07:21 AM

Learning C before C++ only means that once you move to C++ you need to forget all the things no longer needed. Why should you learn to use c strings when you can start with std::string? Or why should you ignore references? Or to use malloc/free instead than new/delete?

A better option would be to learn 'C++ without classes', but still, a lot of languages (Java and C# to start with) are highly OO so you can as well learn C++ the OO way...

I don't see reason why you would want to learn C if you target C++. And I don't see reason to learn Pascal if you want to program with Delphi, for that matter...

#4187168 John Carmack on Ray Tracing

Posted by on 25 March 2008 - 01:59 AM

I think that raytracing will not be a viable options until rasterization will reach that borderline where the quality provided by all those hacks (i.e. fake soft shadows) will no longer satisfy users. When this time will come, we should compare performances of the full quality rasterization approach (wich in the case of shadows is not all that fast too) and the raytracing way of doing things. Others factors will be probably consider, i.e. most of those effects are easy to implement in RT, and I suppose that since RT often uses the same approach to render most of them, HW could be also easier to build.

I was under the impression that Carmack tried to keep a Cautious point of view: as I see it, what he said is something like "RT won't be the main rendering method, but it will be used more in the future". This is not really a discover IMHO...

But RT is not inherently slower than rasterization: simply rasterization can be better taylored and tuned to get better performances paying in quality. Once we reach that point where we no longer accept those limits (may occour several years), perhaps it will become less obvious the advantages of rasterization over RT. I still remember when lighting interpolation between vertices was the only practical way of rendering a game (or even when doing the lighting was done once per face). Many people stated that per pixel lighting would have been simply to slow for realtime applications, and some even used to repeat that we really would have never asked for all that quality...
In the meantime, it would be very nice to see true RT hardware with power comparable to latest nVidia or Ati cards.
I hope that intel larabee will give us more to speak about (or perhaps it wont't affect that debate at all)...

#4143050 Please explain something for me, about ray tracing

Posted by on 20 January 2008 - 06:10 AM

If raytracing was the rendering algo used by games, raytracing gfx cards would be not too much different (as far as their usage goes) from todays one. There will be the need of shaders (pixel, though, not vertex, as I don't think interpolating values across the polygon would have a meaning), of buffers (z buffering would still be useful for post processing operations only, because raytracing already addresses the visibility problem, and other already existing tecnologies.
But the card should implement at least two additional tasks: ray/primitive intersection and spatial accelerartion traversal (and building perhaps). Other than that, once you calculate your pixel, you put it in a screen buffer and then send it to the screen, just as you do today.

By the way, you may able to find some informations about HW RT in those sites:
here and

The (probably) most important project concerning HWRT is this

There is also a library that aims to become the standard for RTRT:

HW raytracing also already exists for high end graphic design, but I don't recall it's name and IIRC last time I checked there was not much informations on their site..