search of the:   for: 
code logs -> 2012 -> Sat, 06 Oct 2012< code.20121005.log - code.20121007.log >
--- Log opened Sat Oct 06 00:00:00 2012
00:48 * Vornicus does some random mathbin shit, gets latex help from NASA
00:50
<&McMartin>
Parsec is also a thermonuclear parser generator
00:50
<&McMartin>
I've never used its like
01:00 You're now known as TheWatcher[T-2]
01:04 You're now known as TheWatcher[zZzZ]
02:10 * Vornicus does some awesome headache math for a friend: converting a bit pattern into a fourier series.
03:25 Geeksoldier [IceChat9@A2BA3E.CCFB1E.606164.F2A8E0] has left #code []
03:34 Attilla [Obsolete@Nightstar-524c008e.as43234.net] has quit [Ping timeout: 121 seconds]
03:49 himi [fow035@Nightstar-5d05bada.internode.on.net] has joined #code
03:49 mode/#code [+o himi] by ChanServ
04:48 CaGeRit [x@Nightstar-f0d9c21f.hr.cox.net] has joined #code
05:03 CaGeRit [x@Nightstar-f0d9c21f.hr.cox.net] has quit [Client closed the connection]
06:39 Derakon is now known as Derakon[AFK]
07:00 Syloq_Home [Syloq@NetworkAdministrator.Nightstar.Net] has quit [Client closed the connection]
08:06 Vash [Vash@1526F6.46E42C.1611FD.5D626F] has quit [[NS] Quit: I lovecraft Vorn!]
08:10 gnolam [lenin@Nightstar-ccbf4b44.cust.bredbandsbolaget.se] has quit [Client closed the connection]
08:11 gnolam [lenin@Nightstar-ccbf4b44.cust.bredbandsbolaget.se] has joined #code
08:27 himi [fow035@Nightstar-5d05bada.internode.on.net] has quit [Ping timeout: 121 seconds]
08:41 himi [fow035@Nightstar-5d05bada.internode.on.net] has joined #code
08:41 mode/#code [+o himi] by ChanServ
08:47 cpux [cpux@Nightstar-c5874a39.dyn.optonline.net] has quit [[NS] Quit: Well, most things get better when I kick them!]
09:04 himi [fow035@Nightstar-5d05bada.internode.on.net] has quit [Ping timeout: 121 seconds]
09:04 You're now known as TheWatcher
09:17 himi [fow035@Nightstar-5d05bada.internode.on.net] has joined #code
09:17 mode/#code [+o himi] by ChanServ
10:30
<&McMartin>
FUCK YES I THINK I JUST LEVELED UP IN VERTEX SHADERS
10:30
<&McMartin>
Now to see if this is only in my own mind
10:32
<&McMartin>
No, I think I've got it
10:32
<&McMartin>
OK, fuck SVAF, instead I should reimplement the non-SVAF parts of Sable's graphical engine as vertex shaders
10:35
<&McMartin>
That said, I kind of feel like a six-year-old showing off that he's worked out how to draw perspective-correct cubes in crayon~
10:43
<&McMartin>
I can have a single static mesh of one, flat triangle strip. I can then repeatedly draw it with a "luminance" texture that is actually a height map. I can use a uniform to say where in that height map to be drawing from, so I don't even have to rebind texel coordinates, just shift the uniform between calls to glDrawElements
10:43
<&McMartin>
And since a vertex shader can check a texture's neighbors as well as its own elements, that also means that the vertex shader can compute its own normals, too, a task Sable needed to do in the CPU.
10:56
< Tarinaky>
Mm, yeah, I know what some of those words mean.
10:56
< Tarinaky>
:p
10:57
< rms>
Same boat
10:57
< rms>
*hifives*
10:59
<&McMartin>
OK, so, the specific insight I had was "I have a way of rewriting my automatic terrain generator so that the rendering is mostly shader-based and *way* more efficient"
10:59
<&McMartin>
The more general insight is "shaders aren't actually for making things look better - they're for making things *easier*"
11:05
<@himi>
Hm
11:06
<@himi>
I didn't realise a vertex shader can get at textures other than the fragment it's part of
11:06
<&McMartin>
You've got the pipeline order backwards there - vertex shading happens before fragments are even generated.
11:06
<@himi>
That said, I haven't done any texture related stuff with vertex shaders, so it's not a shock
11:07
<@himi>
Yeah
11:07
<&McMartin>
(At the level of OGL I'm targeting, the Vertex shader produces the extrema between which the fragments interpolate. Normally this is for normals, colors, and/or texture coordinates, but it can be anything)
11:08
<@himi>
Being able to calculate normals in the shader would be nice - one of my biggest issues with some code I wrote recently was having to precalculate the normals
11:08
<&McMartin>
The trick is that the shader has to somehow know what the stats of its neighbor vertices will be
11:08
<@himi>
Yeah
11:08
< Tarinaky>
The TL;DR is that ShaderGL exposes a programmable machine - and all this implies.
11:09
<&McMartin>
The trick is, if you stick the only bits that matter into a texture, *you can*
11:09
<&McMartin>
Tarinaky: Yes, but the question is how you feed data into that machine, and what that machine can thus operate upon
11:09
<@himi>
I've thought of using a geometry shader, but I've been targeting 3.0 as my base and I don't know about the support for them
11:09
< Tarinaky>
Data, data and data :p
11:10
<&McMartin>
Yeah, geometry shaders were not added standard until 3.2 - none of my machines have them
11:10
<&McMartin>
Also, I am targeting 2.1.
11:10
<&McMartin>
Also also, yeah, I had originally abandoned this project because I thought a geometry shader was necessary.
11:10
<&McMartin>
But nope, texture abuse saves the day
11:10
<&McMartin>
If it's even abuse
11:10
<@himi>
And yeah, abusing textures is great
11:10
<&McMartin>
This is why I'm saying "gee, I leveled up to something very low and am now showing off my crayon drawing that is TOTALLY 3D MOM LOOK"
11:11
<@himi>
I think people have been abusing textures since computer graphics started
11:11 * himi nods
11:11
<@himi>
I'll have to check out my code and see what I can do with textures
11:11
< Tarinaky>
And this is why mommy drinks :p
11:11
<&McMartin>
Secret City was an awesome TV show and I will hear nothing against it!
11:12
<&McMartin>
himi: That said, 3.0 changes how textures work in the shader language
11:13
<&McMartin>
But I wuold imagine that power will only incrase.
11:13
<@himi>
Yeah, I didn't look at it in great detail because I haven't been doing anything with texturing, but I'll have a closer look
11:14
<@himi>
What I recall seeing in passing was fairly powerful and generic
11:15
<&McMartin>
Yeah, it's baically "get texture value at these coordinates", with a few variations that are optional and the options are different for vertex and fragment
11:15 * himi nods
11:15
<&McMartin>
The part I'm less clear on is how you get which texture to use into the shader program in the firs tplace.
11:15
<&McMartin>
In 3.0, it's probably as a Uniform of some kind, but 2.1 may only let you have one at a time via fixed functionality binding.
11:17
<&McMartin>
That said, while I'm sure you've already determined that 3.0 is sufficiently compatible for your needs, I should probably also raise the results of my own compat research
11:17 * himi nods
11:17
<&McMartin>
Which is that 3.0 pretty much means "video card designed for fancy 3D in post-Vista operation", and is as such rather more restrictive than "well over a major version behind" looks
11:17
<&McMartin>
(It's equivalent to early D3D10)
11:18
<@himi>
Yeah, later 3.x is actually more flexible than 3.0, as far as I can tell
11:18
< gnolam>
<McMartin> In 3.0, it's probably as a Uniform of some kind, but 2.1 may only let you have one at a time via fixed functionality binding.
11:18
< gnolam>
?
11:19
<&McMartin>
gnolam: that "may" means "I haven't done the research, but the difference I've noticed between GLSL 1.20 and GLSL 1.30 is that GLSL 1.20 talks about the nominally fixed functionality components a Hell of a lot more"
11:20
<@himi>
3.0 and later moves a whole lot more fixed functionality into the depreciated side
11:20
<&McMartin>
Also, and maybe it's an artifact of time, stuff targeting 2.x just goes and uses glNormalPointer instead of glVertexAttribPointer and deciding that attrib array 1 is the normals.
11:20
<&McMartin>
Yeah, 3.x defines a much more generic communications interface out of the excess in 2.x and expects you to use it for everything.
11:21
<&McMartin>
Since I'm evolving 1.2 code here, as well, there's also less of *that* going on.
11:21 * himi nods
11:22
< gnolam>
You set the sampler to the number of the texture unit you bound the texture to.
11:23
<@himi>
I explicitly started off targeting 3.3, since that's the latest version that my hardware supports, and I was looking at doco that was mostly oriented towards 4.0+ with backwards compatibility info for 3
11:24
<&McMartin>
gnolam: That sentence makes no sense to me unless by "texture unit" you mean "the 2D texture".
11:24
<@himi>
Kind of irritating given most of the tutorials that get linked do a whole lot of talking about the fixed functionality, and even some immediate mode rendering
11:24
< gnolam>
E.g.
11:24
<&McMartin>
himi: Yes, the choice seems to be between that and one that spends 14 chapters getting to the perspective transform.
11:24
< gnolam>
/ In the shader
11:24
< gnolam>
uniform sampler2D foo;
11:24
< gnolam>
uniform sampler2D bar;
11:24
< gnolam>
/ In your program
11:24
< gnolam>
glActiveTexture(GL_TEXTURE0);
11:24
< gnolam>
glBindTexture(GL_TEXTURE_2D, fooTextureID);
11:24
< gnolam>
glActiveTexture(GL_TEXTURE1);
11:24
< gnolam>
glBindTexture(GL_TEXTURE_2D, barTextureID);
11:25
< gnolam>
glUniform1i(GetUniformLocation("foo"), 0)
11:25
<@himi>
heh
11:25
< gnolam>
glUniform1i(GetUniformLocation("bar"), 1)
11:25
< gnolam>
... that got sort of horribly mangled, but.
11:25
<@himi>
Yeah, a lot of startup work, but the end result is a lot more powerful
11:25
<&McMartin>
gnolam: Aha! OK, glActiveTexture was the call I was not seeing
11:26
<@himi>
And easier to modify, too, modulo the incredible difficulty of getting debugging info
11:26
<&McMartin>
Also, it is from after the last time I learned~
11:26
<&McMartin>
himi: The difference between fixed and programmable fucntionality there is *one line of shader code*
11:26
<&McMartin>
vs. 1 API call (glPushMatrix)
11:27
<&McMartin>
So I am Extremely Unimpressed by that argument in the specific instance of Perspective Transform and Modelview Matrix.
11:27
<&McMartin>
gnolam: glActiveTexture was introduced in 1.3!
11:27
<&McMartin>
That is, like, The Future
11:27
<&McMartin>
have I mentioned my knowledge is way out of date? because it is
11:28
< gnolam>
Heh.
11:28
<&McMartin>
(As I think I mentioned above - the code that I'm evolving here was targeting 1.2 because that's the what the *good* machines in the uni lab supported at the time.)
11:29
<&McMartin>
(So it's what the state of the art was the last time I really studied this.)
11:39
<&McMartin>
OK, it looks like even in GLSL 1.20, code like what you describe is the only way to initialize a sampler2D.
11:39
<&McMartin>
There is no equivalent to, say, gl_FrontMaterial or gl_ModelViewMatrix.
11:44
<@himi>
I do have to say, once I got past the initial hurdles I found dealing with GLSL/OpenGL fairly pleasant
11:45
<&McMartin>
Shaders mean that my old description of OpenGL does not apply as firmly
11:45
<&McMartin>
But I don't have a good new metaphor yet
11:46
<@himi>
What was your old description?
11:46
<&McMartin>
My old metaphor was that programming OpenGL (now, "programming OpenGL with fixed functionality") is like programming a robot to go toggle in the program you actually want to run into some mainframe located at the bottom of the sea.
11:46
<@himi>
heh
11:46
<&McMartin>
Looking at some of these GLSL demos, I think the new world may instead be "like programming a swarm of nanobots to do the Wave"
11:48
<@himi>
Yeah, explicitly exposing the parallelism in the card actually makes it /easier/
11:48
<@himi>
I think
11:49
<&McMartin>
It does require a phase shift
11:49
<&McMartin>
If you're used to framebuffer graphics
11:49
<&McMartin>
By which I mean, "if you've ever done any 2D work, ever, in days of yore"
11:49 * himi nods
11:49
<&McMartin>
You're used to thinking of a canvas that you draw on with draw operations
11:49
<&McMartin>
This is more like e-ink.
11:50
<&McMartin>
This makes it easier in that you know where the hard parts are
11:50
<@himi>
. . . I don't get that
11:50
<@himi>
The e-ink description
11:50
<&McMartin>
Each pixel decides what color it's going to be on its own.
11:50
<&McMartin>
The hard part is getting it the info it needs to make that decision.
11:50 * himi nods
11:50 Kindamoody|afk [Kindamoody@Nightstar-5b3db968.telia.com] has quit [Connection reset by peer]
11:51
<&McMartin>
This is what had tripped me up with the heightmaps - I didn't have a way to get the vertices information about their neighbors.
11:51
<@himi>
What did you do?
11:51
<&McMartin>
Then came the insight: "Wait, yes I do, because the mesh's properties are known because they're either part of the texture or they're entirely static"
11:51
<&McMartin>
Since I wrote this code back in the 1.2 days, what I *actually* did was use immediate mode~
11:51
<&McMartin>
But just for the dynamic terrain.
11:52
<@himi>
Ah, yes - same problem as with getting normals
11:52
<&McMartin>
Right, the normals are based on your height, and on the locations of your neighbors
11:53
<&McMartin>
Well, "on the location of you and your neighbors"
11:53
<@himi>
Yeah
11:53
<&McMartin>
The terrain itself was a simple extensible midpoint displacement fractal ("plasma fractal") interpreted as a heightmap
11:54
<&McMartin>
I'm sure you can do plasma fractals in GLSL too but there's much less reason to want to do so - this is something that only changes once every thousand-odd frames.
11:54 * himi nods
11:54
<&McMartin>
That's far enough out that I don't know whether you're supposed to mark the relevant buffer data as GL_STATIC_DRAW or GL_DYNAMIC_DRAW.
11:54
<@himi>
I think static draw
11:55
<&McMartin>
Well, there's also GL_STREAM_DRAW, which it is Definitely Not.
11:55
<@himi>
Dynamic draw seems to be for cases where the buffer is only reused a handful of times
11:55 * himi nods
11:55
<&McMartin>
(the mesh itself is, of course, stati draw because the whole point here is that It Never Changes)
11:55
<&McMartin>
... actually, I forget whether textures even get to have this hint.
11:55
<@himi>
I doubt it makes any difference in any case, because they're mostly hints
11:58 Kindamoody|afk [Kindamoody@Nightstar-5b3db968.telia.com] has joined #code
11:58 mode/#code [+o Kindamoody|afk] by ChanServ
11:59
<&McMartin>
Not seeing such hints in glTexImage2D anyway.
11:59
<&McMartin>
(Unlike, say, glBufferData)
12:33 Attilla [Obsolete@Nightstar-7d877edc.as43234.net] has joined #code
14:13 CaGeRit [x@Nightstar-f0d9c21f.hr.cox.net] has joined #code
14:18 CaGeRit [x@Nightstar-f0d9c21f.hr.cox.net] has quit [[NS] Quit: CaGeRit has left the channel.]
14:22 You're now known as TheWatcher[afk]
14:33 Derakon[AFK] [Derakon@Nightstar-a3b183ae.ca.comcast.net] has quit [Ping timeout: 121 seconds]
14:34 Derakon[AFK] [Derakon@Nightstar-a3b183ae.ca.comcast.net] has joined #code
15:07 Syloq_Home [Syloq@NetworkAdministrator.Nightstar.Net] has joined #code
17:13 cpux [cpux@Nightstar-c5874a39.dyn.optonline.net] has joined #code
19:21 Outpost[College] [NSwebIRC@ECA6CF.39A83B.67F921.971876] has joined #code
19:21
< Outpost[College]>
Anyone know forks/signals/signal masing..?
19:21
< Outpost[College]>
*masking
19:24 Vash [Vash@Nightstar-3ba4108e.wlfrct.sbcglobal.net] has joined #code
19:24 mode/#code [+o Vash] by ChanServ
20:03 ToxicFrog [ToxicFrog@ServerAdministrator.Nightstar.Net] has quit [Connection reset by peer]
20:04 ToxicFrog [ToxicFrog@ServerAdministrator.Nightstar.Net] has joined #code
20:35 You're now known as TheWatcher
21:19 Derakon[AFK] is now known as Derakon
21:19 mode/#code [+ao Derakon Derakon] by ChanServ
21:44 Outpost[College] [NSwebIRC@ECA6CF.39A83B.67F921.971876] has quit [[NS] Quit: Page closed]
22:05 gnolam [lenin@Nightstar-ccbf4b44.cust.bredbandsbolaget.se] has quit [Client closed the connection]
22:05 gnolam [lenin@Nightstar-ccbf4b44.cust.bredbandsbolaget.se] has joined #code
23:12 * Derakon finds himself trying to help two other Angband devs sort out how to use Mercurial, when he barely knows more than them to begin with...
23:13
< rms>
Heh
23:13
< rms>
Did that with git a few times
23:13
< rms>
I use it all the time, just not with anything more complicated with add->commit->pull->push
23:13
<&McMartin>
They're wonderful until you try to use them for their intended purpose~
23:14
<&Derakon>
Part of the issue here is that they're used to using Git, but I gratuitously switched to Mercurial for this project, since a) it started as my own pet project, and b) I hate Git's mnemonics.
23:15
<&Derakon>
(Then it started getting traction with the rest of the dev community...)
23:19
< rms>
McMartin: example?
23:20
<&McMartin>
DVCS justifications all eschew the notion of some kind of master repository, becuase that's all client-server and not DISTRIBUTED!!!! and thus it is useless
23:21
<&McMartin>
So their intended purpose is for people to all be nominally working on the same project, but nobody's sets of historical commits is actually a subset of anyone else's.
23:21
<&McMartin>
And fuck that noise~
23:21
< rms>
Heh
23:21
< rms>
I use them because I want to have source-control features without access to the master repo
23:22
<&Derakon>
I use them because fuck not being able to commit your code until it's working perfectly.
23:22
<&Derakon>
Commit early, commit often.
23:22
< rms>
That too
23:22
<&McMartin>
Yes. In this model, the "master repo" is the one whose contents are the subset of everyone else's.
23:22
<&McMartin>
They should also be equivalent to the *intersection* of everyone else's, and they should be the last known-good state for everyone.
23:24
<&McMartin>
But once you do that you're basically doing SVN with either invisible branches or server-side repo-hacking to make your previously visible branches vanish.
23:24
<&McMartin>
Well, OK. SVN 1.6 or later.
23:24
<&McMartin>
And if SVN 1.6 exactly you're also doing it without shitting hidden files in every last subdirectory
23:52
< ToxicFrog>
McMartin: wait, what?
23:52
< ToxicFrog>
I have literally never seen this
--- Log closed Sun Oct 07 00:00:15 2012
code logs -> 2012 -> Sat, 06 Oct 2012< code.20121005.log - code.20121007.log >
 search of the:   for: 

[ Latest log file ]