pouët.net

the original thesis work was developed embbebed into an existing c# 3d modeling application, thats pretty much the only reason why i kept developing it on c#

System.Demo.Minimalartifact.Technology.Texture.WTF.Pouet.Thesis.Dark.n.Long.GetTexture()

undefined function in line 1[]

ps, remove the whitespace before "xture()", then it works. Also a semicolon at the end might help.

oh! that makes sense! why didnt i see that?!

that's the pouet forum inserting whitespaces into insanelylongwordshereisnowhitespacewaitforitpouetinsertsoneatanypointinthisverylongwordthankyouandgoodbye

ah, so it is. why wont the pouet admins ever fix that thing? its so annoying.

if it's just for testing purposes, i'd suggest mocking it up in python or similar script language.

Dear sceners, aparently "real" Perlin noise is obsolete, please move on to wavelet noise

1) How are you dealing with creating textures of different size?

* usually, you will need only two sizes: high quality and low quality
* parametrize not by pixels, but relative to the size of the image, like "blur by 0.03"
* images will differ. but usually that is acceptable

2) a generator that creates a buffer with random pixels on it, how would you deal with the same problem as above?

* don't do dots
* use perlin noise and subtract to create your pixels, that will scale.

3) quality vs. speed vs. size: which one do you favor?

* go for 16 bit for each color channel, like 64bit for RGBA. it hurts a lot, but it's worth it.
* when in doubt, make it a switch: slow or ugly.
* many ops are bandwidth limited, when not, optimize the hell out of them until they are bandwidth limited. you usually get some math & quality for free.

4) what is an (uncompressed) code size I should aim to? currently it's 15k including PNG export.

* you don't need PNG export in an intro
* use the mapfile feature of kkrunchy to check code size
* don't care about uncompressed code size, never optimize for uncompressed code size, only compressed code size counts, and it's completely different.
* get a prototype with 3d, texgen, sound, timelining, splines, etc running, then decide where to put the remaining kb's
* make sure the graphicians work on the textures justify the coders work and the code size. a 10k texgen generating 10 crappy textures is bad.

chaos: thanks for your reply - was exactly what I was looking for as an answer - straight facts with no extra info.


It's because I currently have no GUI.
Artists cannot work on it atm ...


On Linux? I am currently working with UPX, and compressed size is 9k.

i think artists who refuse to work without a shiny GUI are pussies or fiver2.

are you sure you need a gui? who's your artist? make sure you design the gui in communication with the artist. if you're the artist yourself, why bother? make a window with a gl screen on the left and a text editor on the right, and compile shaders on the fly, and you're up and running.