pouët.net

Texture generator questions

category: general [glöplog]
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#
added on the 2008-08-30 05:02:23 by psenough psenough
System.Demo.Minimalartifact.Technology.Texture.WTF.Pouet.Thesis.Dark.n.Long.GetTexture()
added on the 2008-08-30 08:45:49 by rmeht rmeht
undefined function in line 1[]
added on the 2008-08-30 13:38:21 by psenough psenough
ps, remove the whitespace before "xture()", then it works. Also a semicolon at the end might help.
added on the 2008-08-30 13:48:45 by kb_ kb_
oh! that makes sense! why didnt i see that?!
added on the 2008-08-30 13:53:38 by psenough psenough
that's the pouet forum inserting whitespaces into insanelylongwordshereisnowhitespacewaitforitpouetinsertsoneatanypointinthisverylongwordthankyouandgoodbye
added on the 2008-08-30 14:00:21 by bartman bartman
ah, so it is. why wont the pouet admins ever fix that thing? its so annoying.
added on the 2008-08-30 14:07:46 by psenough psenough
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
added on the 2008-08-30 21:04:46 by winden winden

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.
added on the 2008-08-30 21:57:26 by chaos chaos
chaos: thanks for your reply - was exactly what I was looking for as an answer - straight facts with no extra info.

Quote:
* you don't need PNG export in an intro
* 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.

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

Quote:
* use the mapfile feature of kkrunchy to check code size

On Linux? I am currently working with UPX, and compressed size is 9k.
added on the 2008-08-30 23:09:51 by LiraNuna LiraNuna
Quote:
It's because I currently have no GUI.
Artists cannot work on it atm ...


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.
added on the 2008-08-31 08:23:05 by skrebbel skrebbel

login