Procedural synthesis

by Dastard on 03/06/2006 03:31, 24 messages, last message: 05/23/2007 04:19, 4852 views, last view: 05/05/2024 12:56

Wouter/Aardappel, whichever you prefer to go by, have you considered experimenting with procedural synthesis of textures/animations/sounds/etc.?

   Board Index   

#5: Blast from the past

by Julius on 05/07/2007 16:39

Maybe this would be a nice project to integrate into Sauer?

http://sourceforge.net/projects/fxgen/

Also there are quite a few semi decent open-source tree generators out by now.
For example:
http://opentreelib.sourceforge.net/
http://ngplant.sourceforge.net/

reply to this message

#6: ..

by Captain_Ahab on 05/08/2007 01:03

I don't think procedural animation would be good..as far as I can think of, it relates to rag-doll stuff or boxes/barrels toppling nicely. Wouldn't that require models with armatures and a rigid body physics system such as bullet or ODE?

I'd rather have a high framerate although being able to move mapmodels during play would be nice.

procedural mapping should be done in cubescript...an example

for a giving location, begin a drunkard's walk...at each step raise the level by one ( or lower it if you want ditches/valleys ). After performing that a few times, smooth it out. If cubescript can determine the slope of a face, let it choose a texture type to apply. That'd take care of grunt work whereupon you could go back and hand tune and tweak it.

just an idea for now. I still have lots to study and learn about cube2 to do anything useful like that yet

reply to this message

#7: Re: Blast from the past

by Aardappel_ on 05/08/2007 08:50, refers to #5

the fxgen is a nice tool, though I am not sure what there is to integrate... it can be used to produce textures.

Both those vegetation tools have a different idea of "realtime" than I do... I don't want to spend a million polys on a single tree.

reply to this message

#8: Re: Blast from the past

by annon on 05/08/2007 17:23, refers to #7

Well if I understood Fxgen correctly than the textures are stored as a series of operations, instead of individual fixed pixels.
If all textures in Sauerbraten would be stored in such a format, than the textures could have any or better a \\\"unlimited\\\" resolution (depending on the PC, e.g. perfect pixel<->texel match) and could be modified on the fly (for example by altering them to look wet etc) and also easily altered by the mapper for any purpose in realtime. In addition to that the complexety of the operations could be altered depending on the speed of the computer.
Disadvantages are surely a more computer generated look I guess, and probably also a bit less artistic freedom of the textures. But that is the price to pay for prodedural effects I guess.

Concerning the trees, yeah that isn\\\'t really \\\"real-time\\\" yet. But they are working on a automatic LOD system for these trees, which would make the scalable and suited for real-time.
Especially this:
http://www.ogre3d.org/phpBB2/viewtopic.php?t=30170
seems to be a promising approach for LODs.

reply to this message

#9: hmm

by Ringo Starr owns n00bs on 05/09/2007 00:30

As a person who makes textures for Sauerbraten, I would NOT Like this.

reply to this message

#10: ..

by Acord on 05/09/2007 00:47

It's the same idea used in .Kkrieger (http://212.202.219.162/kkrieger). Using procedural textures is a very GOOD idea, and given then right interface, would be quite beneficial - especially where distribution is concerned.

The issue of course is the interface.

While a lot of folks feel that it would take the art out of it, it still requires just as much artistic talent as making regular textures - if not moreso, due to the fact that you can not use photographic source material.

A procedural texture uses a drawing program. An artist uses the program, and instead of creating a huge image file, they create a file which is a recording of their actions.

This recording can be far, far more compact than the actual image file. Maybe even 1/1000th the size.

The recording is then "played back" when the software is installed in order to generate an identical texture. So a 4k file can easily become a 4000k 2048x2048 lossless PNG, instead of a lossy JPG.

The downside is that you would require a *lot* of texture generators in order to make such a thing useful. On the other hand, if the features and tools were rich enough, you could sell the technology to interested game companies for an ungodly amount of money.

And programming that many texture generators would take a long, long time and lots of work.

So, it's a FANTASTIC idea, but a bit on the unrealistic side as far as difficulty involved. And regenerating all of those textures can take a *lot* of time during installation, depending on how complicated the functions that are utilized become.

reply to this message

#11: Re: ..

by eihrul on 05/09/2007 04:31, refers to #10

If no one has noticed, all our content is donated or used from free-for-non-commercial-use sources, meaning stuff like this is pretty much worthless for us because we can't just tell in-house artists to make art in a given format, the art comes in whatever format it comes, especially if it is quality art.

reply to this message

#12: Re: ..

by annon on 05/09/2007 13:43, refers to #11

Well, if this system would work correctly than the mappers would make the textures on the fly while mapping (more or less... there should be some pre made one to modify of course). IMHO (as an artist btw) this is actually much better than depending on premade static textures.

reply to this message

#13: Re: ..

by tentus_ on 05/09/2007 14:26, refers to #10

By the way, a much newer version is available at http://theprodukkt.com/

Some interesting stuff in here, I like the idea (even if the application is somewhat inapplicable). I could see a much simpler method being feasible for Sauer (ie, being able to create textures in a cfg by overlaying PNGs). Terrain painting would be useful too (having a texture fade into existence on top of another texture). But I need to do some more research first.

reply to this message

#14: Whoops. >_>

by tentus_ on 05/09/2007 23:04, refers to #13

I can't believe it took me this long to realize I omitted a couple of sentences from my post. I'm a fool. I was also going to say in the middle of that:
Acutally, there is not a newer version of the game .Kkriegor, but the demo .debris uses a more complete engine that the .Kkriegor beta uses.
Some of the camera stuff they implemented in .debris would be quite useful for Sauer as well, such as camera shake. I know that a lot of people really hate it, but I prefer to have my virtual head shake when I get hit by rockets. Makes things a bit more immersive, for me.

reply to this message

#15: Re: Blast from the past

by Johann on 05/10/2007 08:09, refers to #7

Hello, I'm the author of FxGen Library and tool, so I follow cube engine evolution from the start and I like engine simplicity and efficiency. My goal is to improve my tool in order to see fxgen used into games engine like cube. So If your are interested I think it could be very nice to reduce textures file size, and modify fxgen tool in order to integrate real time texture editing in sauerbraten. Johann.

reply to this message

#16: Re: Blast from the past

by sinsky on 05/10/2007 16:37, refers to #5

I haven't downloaded the other two utilities but just tried ngplant and it seems too cool to be free :) Sauer-wise, it can be used to make plant models and then export them in .obj format. Then with a bit of texturing, it should be easy to make a great variety of plant mapmodels.

reply to this message

#17: Re: Blast from the past

by Julius on 05/10/2007 21:20, refers to #15

lol, sometimes it shows how tiny the open-source game community really is!
Welcome to these forums, Johann.

Back on topic: It would probably be beneficial to both Sauer and FxGen if it was implemented as a sort of proof of concept.
It could probably work along side traditional textures quite well for the time beeing and an in game editor could be added into the sauerengine once the base support for procedural textures is really mature.

Maybe you could make that your side project?

reply to this message

#18: ..

by Zorro on 05/11/2007 06:06

I vote yes on this. By no means does that mean all the existing artwork needs to be converted or anything, it would just be another of the seemingly endless item's in sauerbraten's visual effects arsenal.

Adittionally, I think animated textures would bea nice thing to see possible.

reply to this message

#19: ..

by Julius on 05/19/2007 23:15

FxGen now has its own community webpage:
http://www.fxgen.org/

The the 0.4 version should be out by the end of the month.

reply to this message

#20: I found one! woohoo!

by randomcivilian [just found linux] on 05/21/2007 04:53

Heres one that i found when i was looking at the 96kb FPS that was in Game Informer this month

http://www.werkkzeug.com/home

reply to this message

#21: ..

by Geartrooper on 05/21/2007 09:05

procedural textures would only be applicable to energy fields and force shields, etc. the mappers are a bit too advanced in vision to rely on obscure textures. Sauer as yet has no energy fields. but if it does I would suggest using procedural textures.

reply to this message

#22: Re: ..

by Julius on 05/21/2007 13:30, refers to #21

Procedual textures really arn't what you describe as "obscure textures".

Sure that open-source lib FxGen still needs a long way to go, but you did see what can be done with Werkkzeug or this other commercial lib:
http://www.profxengine.com/
right?

reply to this message

#23: Re: ..

by Eivets on 05/21/2007 21:23, refers to #22

There is a game called RoboBlitz using the Unreal 3 engine together with Pro FX engine. It looks decent. The editor for generating the input for Pro FX (MapZone) is free by the way. And it can generate very good texture images, which you can save to disk in any resolution...

reply to this message

#24: ..

by Zorro on 05/23/2007 04:19

I am one who seldomly will be found praising proprietary software, but that profx engine made my jaw drop open (looking a the demos).

reply to this message

   Board Index