treemagik released free...and..keep an eye on Arbaro!

vermeer · Post by **vermeer** » Tue Feb 22, 2005 10:16 pm

yup...it's all about textured planes ,then...

is not that hard to make, then...

anyway, tested today treemaker.Not bad, though only export as separate objects in 3ds..no biggie if u have ultimate unwrap...or neat use of blender.

uploading the sample tree I made with a quck texturing...one never knows if anyone would like for making coding tests....

one is like 6,700 k, the other 10k..i may have put a wrong file, dunno, as did this uber quick...

uncompress all in same folder

http://uploads.savefile.com/redir/116942.zip

http://uploads.savefile.com/redir/116944.zip

arbaro will do soon uvs, like treemaker do

anyway, any of these tools seem to need quite some retouch after exported, even fixing.ie: objs in treemake rcome with inverted normals...any tool has a disadvantage like this.

vermeer · Post by **vermeer** » Tue Feb 22, 2005 10:20 pm

ouch...

u'll need www.7-zip.com decompressor..its free...is a winzip like.

too lazy now to re upload...
it makes zips not very compatble, but small....

cmoibenlepro · Post by **cmoibenlepro** » Thu Feb 24, 2005 3:07 am

that alpha channel thingy with .tga does still not work for me

In the irrlicht manual it says:

EMT_TRANSPARENT_ALPHA_CHANNEL:
Makes the material transparent based on the texture alpha channel. Only first texture is used. Please note that this material is currenly NOT IMPLEMENTED.

I don't know if it changed with irrlicht 0.8 as Niko changed some tga code... maybe you can ask him...

eXodus · Post by **eXodus** » Thu Feb 24, 2005 3:25 am

TGA Loaders are 100% complete, so my bet is yes

vermeer · Post by **vermeer** » Thu Feb 24, 2005 8:42 am

one curious detail: While Adobe PS 7.01 does not have it (dunno 8 CS) , Gimp for Windows (then gimp in linux too) 2.2.3 , in tga export dialod has a checking mark for if u want the tga origin down at the left or no....this would avoid the need of flipping uvs, the texture it self or extra lines ofcode, and gimp support fully tga 32 bit with alpha channel.

cmoibenlepro · Post by **cmoibenlepro** » Fri Feb 25, 2005 2:06 am

I don't know, it's not because the loader is complete
that texture alpha channel work

etcaptor · Post by **etcaptor** » Fri Feb 25, 2005 2:50 am

I've tried alpha channel for tga even in Irr v.07. with GIMP, and it's works well.

eXodus · Post by **eXodus** » Fri Feb 25, 2005 3:27 am

Photoshop CS has ARGB channels

vermeer · Post by **vermeer** » Fri Feb 25, 2005 8:35 am

"Photoshop CS has ARGB channels"

sorry for my english, but if that means that it has alpha channels, yup, indeed it supports that since elder versions...I remember my times in companies doing tgas with alpha with 5 and 4....and as before i was only a web graphics designer..

what i meant was...in the save dialog, a checkbox to change the origin in the exported tga...this is not in tga exporter of ps 7.01...but yes in gimp.
if that's related with tga issue of flipping, ther u have a workaround..

etcaptor · Post by **etcaptor** » Thu Mar 03, 2005 2:40 pm

vermeer wrote:"
dunno in irrlicht , but in general gam engines, many surfaces/entities, can be a bottle neck...arbaro outputs two groups : trunk+terns, and another group, the leaves. maybe treemagik exports a grou per leaf, dunno.that'd killl any engine, even a low pol tree.

maybe vertices get out un-connected. also a possible reason.

i doubt is using many textures.

You are right. I tried several tools for low polys tree generation and get similar results. If camera is near to leaves the frame rate is going down. From middle distance fps is ok. Next I've tryed to create 20 near placed billboards and get low fps again if camera is near.
Therefore, using of many near placed textures is the reason. But if only one low poly 3d tree is used with two textures results are similar...Strange - only one tree with 90 poys can slow fps from 80 to 13 if camera is near to the leaves.

vermeer · Post by **vermeer** » Thu Mar 03, 2005 4:13 pm

have you tried the with a non-alpha map tga? just solid?

maybe it's the shadows again?

hmmmm....

are the billboards just one face, really? arent em two faces pointing the normals opposite? ie: forning 180º the two normal vectors, that is, you attached a copy of the tga alpha mapped plane, and inverted it?...the 2 too-near planes in some engine I think can produce a calculation huge bottle neck, if I remember well...I'm no coder, i just remember some of coder's team sufferings....

if actually is only one face, was one in ur modeler originally...are u sure when u tell irrlicht "make this face double renderable", doesn't actually duplicate the face and invert its normal?

I know it produced probs in other engines..

etcaptor · Post by **etcaptor** » Thu Mar 03, 2005 5:27 pm

With a non-alpha map tga is same.

Well, let's we compare two models - one is 5500 poly model /person/, and another is 650 low poly model /tree/. Second model drop down fps 3 more times rhen first. I think that this is somehow tih geometry related.

I'll upload one 3ds and x file. You can test it.

http://etcaptor.f2g.net/public/ivtree.3ds
http://etcaptor.f2g.net/public/ivTree1.x

hybrid · Post by **hybrid** » Wed Mar 09, 2005 10:43 am

eXodus wrote:TGA Loaders are 100% complete, so my bet is yes

No, they are definitely not. But they work in most common situations. Currently, only mode 2 TGAs are supported meaning 16-32 bit color mode (i.e. no color mapped 8bits and no grayscale).
The loader does not care for 15/16bit distinction and always flips around. this can be easily fixed, though, by just testing two bits in the header.
I also tried to use a slightly patched version of rdtarga.c from jpeglib directory, which gives access to mode 1 and mode 3, but I did not test my patched alpha channel support yet. Problem is that rdtarga ignores alpha channels since it is intended to feed its output directly into JPEG compression which ignores alpha channels, too.

So at least for the two patches for the current Targa support:

Code: Select all

is_bottom_up = ((ImageDescriptor & 0x20) == 0); /* bit 5 set => top-down */

sets a boolean to distinguish bottom_up from top-down.
For 15bit support one has to correctly calculate

Code: Select all

bytesPerPixel

and correctly set the image format depending on the original value (i.e. 15 or 16).