I create this topic to put here all the stuff can be use to make a HD tremulous
It can be links, pictures, models, textures, animation, and 3D engines.
a little try with a upgrade of the dragoon model
(http://www.mabul.org/moe/up/10/11/12/iw0qwr4v.jpg) (http://www.mabul.org)
I think it's possible to use the nexuiz engine or the xreal engine to get skelton animation, is'nt it ?
Can't you just change the resolution of existing trem to 1920x1080, et voila, trem HD?
btw, that looks horrible, what did you do to the poor thing, cover it in some kind of gooey substance and hit it with a tree?
I like that texture, kick down the brightness in the brightest spots though,
Is that a texture or a somehow failed lighting? The model looks like it has more polys, but I somehow don't like it.
OMG IM MAKING A HD TREMULOUS ALL READY.
Want to help?
We all ready got most of the maps in HD and were pushing up the vertices in all the models to make it more poly.
Were working on the codes to make it HD also.
Were working on Codes, Models, and Graphics.
Also new HUD as well.
Quote from: Lonly on November 12, 2010, 08:21:38 PM
OMG IM MAKING A HD TREMULOUS ALL READY.
Want to help?
We all ready got most of the maps in HD and were pushing up the vertices in all the models to make it more poly.
Were working on the codes to make it HD also.
Were working on Codes, Models, and Graphics.
Also new HUD as well.
Wasn't there some new rule on trolls?
Quote from: Lonly on November 12, 2010, 08:21:38 PM
Were working on the codes to make it HD also.
Hahahaha, HD code?
Quote from: Thorn on November 12, 2010, 08:34:18 PM
Wasn't there some new rule on trolls?
Mostly the cold, ugly ones.
It
is a nice goon render. Move the camera further and give it a black background plz.
My monitor isn't full HD though, I only have 1680x1050.
Guess what, everyone?
I HAVE HD TREMULOUS ALREADY! OMG!!!!11 :o
Mode 0, set custom size to 1920x1080. You're welcome.
Yes, I know I'm godlike like that. See, Lonly, I'm helping our team already.
The textures are tiny. You guys make me laugh, HD renders of low quality objects.
We need quality objects!
I've thought about enlarging the current textures for the aliens then brushing them over with some procedural textures and images to make them look better.
OK, but I just say before:
"a little try with a upgrade of the dragoon model"
I didn't touch to the texture, i just had a little more poly to the model to don't see anymore the edges of it.
I didn't add to much poly because we just need to add a normal map and a bump map to get a better look.
That's it ::)
I increase the size of the original texture and of the height map.
I also add a leopard texture on the original one.
(http://www.mabul.org/moe/up/10/11/13/tzbnzxxh.jpg) (http://www.mabul.org)
that's it, what do you think ?
I think only the armoured, shell part of the head and mouth with those fangs look good with that effect of yours.
The rest of the goon looks pretty terrible, especially feet.
I think it looks oversaturated and the contrast's a bit much, but i'd need a good quality standard goon render to compare to, really.
Quote from: Tremulant on November 13, 2010, 11:40:17 AM
I think it looks oversaturated and the contrast's a bit much, but i'd need a good quality standard goon render to compare to, really.
That's true, a comparison picture would be nice.
the legs have "segments" like the tyrants crown. make the segments go into the goon a little more
Quote from: harraps on November 13, 2010, 11:19:21 AM
that's it, what do you think ?
I still think you should move the camera back and make the background black.
Quote from: jm82792 on November 13, 2010, 08:33:13 AM
The textures are tiny. You guys make me laugh, HD renders of low quality objects. We need quality objects!
I've thought about enlarging the current textures for the aliens then brushing them over with some procedural textures and images to make them look better.
I used reasonably high-res textures on Vega, you should ask people with low-end graphics cards about the awesome framerates they're getting.
Quote from: swamp-cecil on November 13, 2010, 12:25:14 PM
the legs have "segments" like the tyrants crown. make the segments go into the goon a little more
Sadly, as google translate doesn't provide a swamp-cecil option, i'll have to ask you to explain what you're on about.
Some of the textures look as though they've suffered at the hands of jpeg compression at some point, and they are generally fairly low res, but still, all you need for HD trem is trem running at what people consider to be an HD resolution.
This is the comparison screen. ;D
(http://www.mabul.org/moe/up/10/11/13/msulhik6.jpg) (http://www.mabul.org)
I didn't use the same light for the two model.
I use yellow light to look like the sun for my model.
And I use "shader" for the original model.
The legs really look ugly in my opinion. Otherwise it's a nice improvement.
Comparison +1
Anyway, now judging which would please my eyes...
... I would take the left dragoon. From this angle, it looks gorgeous. Atleast it looks interesting. Legs look too rough, especially front legs, but new texturing fits for me.
Nice work anyway. :)
Thanks for posting the comparison, i can certainly see some improvements now but i still don't feel the new textures are quite right, the yellow colour cast doesn't help, do both of the renders have the same lighting?
yeah, legs are the main thing that need redoing...
All we need is someone to take the current textures blow them up and add in detail.
(http://img34.imageshack.us/img34/5687/beforeaftert.jpg)
Before is on the left.
After is on the right.
And we didn't even do all the effects yet.
Looks good harraps though.
+1
I have sod-all idea what i'm doing, but hey, doesn't that noise look nice.
(http://i.imgur.com/K5QYU.jpg)
That's antiailising issue(I know it's being spelled wrong).
You can tell trem to do some of that work and then for some people your GPU to make it even cleaner
Now if we mod and replace the textures included with the generic maps we can get somewhere!
Make sure they are made by yourself or are properly licensed, then we can have mods.
ATCS, Karith and your stock maps are what most user created maps feed off of texture wise.
Quote from: jm82792 on November 14, 2010, 02:22:27 AM
That's antiailising issue(I know it's being spelled wrong).
You can tell trem to do some of that work and then for some people your GPU to make it even cleaner
You what? Who's pointing out problems with aliasing?
goon blown up and painted over with shitty textures ftw... http://i.imgur.com/s9BrE.jpg
I haven't even bothered to test this one, it's bound to be horrible, if you want to pull this off i have a feeling that you're going to need someone capable of repainting the textures, not just brushing over them with others.
/r_ext_multisample 4 or something r_ext_multi* should turn on antialising
Quote from: Lonly on November 13, 2010, 11:38:08 PM
[img]
Before is on the left.
After is on the right.
And we didn't even do all the effects yet.
Looks good harraps though.
+1
That kind of looks like you just threw in a few lighting/contrast effects and maybe sharpened it a bit. Anything else?
I thought he just scaled, unsharped and screwed up the colours.
Dragoon, now with stone paved legs and leather patches...
http://imgur.com/DDQ3j.jpg
Lonly, I really like your textures but I've got 2 questions.
Why don't you use the Xreal engine if your are making a HD tremulous?
You're saying you increase the polycount and the texture size, but why don't you use heightmap or normalmap and md5 models.
Those things don't need a lot of work to make.
Quote from: harraps on November 14, 2010, 12:25:41 PM
Lonly, I really like your textures
Can you explain why, so that i may like them too?
kind of a improvement from 512x512 ones to me, but I'm far far away from calling it HD quality.
Quote from: Tremulant on November 14, 2010, 02:13:00 AM
I have sod-all idea what i'm doing, but hey, doesn't that noise look nice.
(http://i.imgur.com/K5QYU.jpg)
Doing Noise Reduction...
Mind telling me how you did that?
Quote from: harraps on November 14, 2010, 12:25:41 PM
Lonly, I really like your textures but I've got 2 questions.
Why don't you use the Xreal engine if your are making a HD tremulous?
You're saying you increase the polycount and the texture size, but why don't you use heightmap or normalmap and md5 models.
Those things don't need a lot of work to make.
I'm considering using XReal, it looks really good.
Quote from: Lonly on November 14, 2010, 07:16:03 PM
Quote from: Tremulant on November 14, 2010, 02:13:00 AM
I have sod-all idea what i'm doing, but hey, doesn't that noise look nice.
(http://i.imgur.com/K5QYU.jpg)
Doing Noise Reduction...
Mind telling me how you did that?
Erm, how i did what? Do you think i removed the noise? Left's before, right's after, i added it, to give the false impression of extra detail at higher resolutions.
texture's here http://i.imgur.com/TxjRI.jpg
HD Rifle (Without Noise) and HD Flash...
(http://img715.imageshack.us/img715/8988/tremulous20101114154034.png)
I took the one Tremulant gave me and applied Color Vibrant.
Quote from: Lonly on November 14, 2010, 09:03:04 PM
HD Rifle (Without Noise) and HD Flash...
[img]
I took the one Tremulant gave me and applied Color Vibrant.
You don't make the graphics for a whole game using filters. Fact.
tremulous after photoshop filters?
looks like some seriously hard work.
Oh, but lonly, does that mean that all the hard work you did on:
Quote from: Lonly on November 13, 2010, 11:38:08 PM
(http://img34.imageshack.us/img34/5687/beforeaftert.jpg)
is wasted?
You're supposedly a pr0 modder who's about to start an xreal port of trem and yet you decided to take my amateurish attempt and fuck it up further, rather than doing something original with your leet skills? Curious.
Come on people, if you can't even manage to produce something less half-arsed than my attempt, don't bother...
Quote from: Tremulant on November 14, 2010, 09:26:34 PM
Oh, but lonly, does that mean that all the hard work you did on:
Quote from: Lonly on November 13, 2010, 11:38:08 PM
[img]
is wasted?
You're supposedly a pr0 modder who's about to start an xreal port of trem and yet you decided to take my amateurish attempt and fuck it up further, rather than doing something original with your leet skills? Curious.
Come on people, if you can't even manage to produce something less half-arsed than my attempt, don't bother...
He supposedly did some original models for the [FuN] mod, but I still haven't seen it. I smell vaporware.
I lost all the models from the old FuN Mod when my computer broke.
We don't have it anymore. It was on the server at one time, so some people may still have it.
+
I don't have Adobe Photoshop, I've been using Gimp.
Quote from: Lonly on November 14, 2010, 10:16:14 PM
I don't have Adobe Photoshop, I've been using Gimp.
Same here, thanks for the PM, lonly, btw.
No, i don't particularly feel like doing the same for the shotgun for you, but i will tell you roughly what i did.
Open original texture, scale to 400%, apply gegl's bilinear filtering(you'd probably get better results with g'mic's anisotropic noise reduction but i couldn't be bothered to install it on this box at the time), add correlated rgb noise to a sensible level.
Quote from: Tremulant on November 14, 2010, 10:47:41 PM
Quote from: Lonly on November 14, 2010, 10:16:14 PM
I don't have Adobe Photoshop, I've been using Gimp.
Same here, thanks for the PM, lonly, btw.
No, i don't particularly feel like doing the same for the shotgun for you, but i will tell you roughly what i did.
Open original texture, scale to 400%, apply gegl's bilinear filtering(you'd probably get better results with g'mic's anisotropic noise reduction but i couldn't be bothered to install it on this box at the time), add correlated rgb noise to a sensible level.
Thank you
That's it, scale it and keep the ratio or trem will spit it out.
Although dding more detail or totally doing new ones would be much better.
I found something in my language !? :o
http://tremulous-fr.org/forum/index.php?p=low&mode=topic&id=638&sid=25e4245bc2d0115ec7a5c9150ff16a2b
Maybe the most interesting thing you could found.
and what is it exactly? looks like a load of xreal screenshots and trem with some noise and a silly, though admittedly pretty, over the top hud.
QuoteVotre travail est tout simplement remarquable ! (Google translation: "Your work is simply outstanding !")
I see no "work" on that thread, only demonstrations of features that are already available in most modern games. I'm filing this under "vaporware".
The only thing that scares me about xreal porting is getting the physics of the game.
Models, animations and crap aren't the scary/hard part, well not easy but it's self explanatory and has instant feedback, plus is hard to mess up.
Quote from: jm82792 on November 16, 2010, 07:02:04 AM
The only thing that scares me about xreal porting is getting the physics of the game.
What? XreaL has the same physics as Q3(which Tremulous is based off of). It's the same game engine as ioquake3, with a re-written renderer.
What I mean by the physics is the gameplay because from what I can understand Xreal uses MD3's(our current assets as place holders) and when you have stuff that already works we can upgrade them later.
Quote from: jm82792 on November 16, 2010, 04:05:36 PM
What I mean by the physics is the gameplay because from what I can understand Xreal uses MD3's(our current assets as place holders) and when you have stuff that already works we can upgrade them later.
You're confusing like 5 different things here.
Xreal uses Md5 and mtf formats for shaders.
oh and lonly.... why dont you SHOW us something, instead of asking people do stuff for you
also HD trem? they're gonna come out with 1.2 and completely null out your "HD TREM" project.
If you want to develop, go learn first... then maybe, just MAYBE, people might respect you a little.
Working 6 days a week has been taking some toll on my brain :P
Quote from: Tamaru on November 17, 2010, 12:45:19 AM
Xreal uses Md5 and mtf formats for shaders.
*mtr
And it can use md3 as well, and in Q3compat mode can read .shader files.
It'll be funny when these HD trems are about to be released and 1.2 shows up.
Quote from: CreatureofHell on November 17, 2010, 08:48:14 PM
It'll be funny when these HD trems are about to be released and 1.2 shows up.
Not if one of them comes out before Thursday.
Frankly, if you want a higher quality render output, it's not so much the models that need to be changed. Rendering lots of polys is still hard and a waste of time. The client engine really needs to be written to include some form of modern bump mapping (http://en.wikipedia.org/wiki/Bump_mapping) such as parallax (http://en.wikipedia.org/wiki/Parallax_mapping) or normal (http://en.wikipedia.org/wiki/Normal_mapping) mapping so that more complicated geometry can be simulated without significant increases on hardware requirements. Displacement (http://en.wikipedia.org/wiki/Displacement_mapping) mapping would be really nice. Solving graphics ugliness by increasing game model detail is the brute force method and isn't really as effective as other, cheaper (in terms of hardware load) solutions.
Also, none of these improvements are going to look really good unless and until we get dynamic lighting and soft shadows.
'High Definition' is marketing bullshit. As has been noted already, its only real technical meaning has to do with display resolution. When used as a descriptor in any other context it's meaningless (do commercials for 'HD audio' bother anyone else?).
Quote from: Fox One on November 17, 2010, 09:34:54 PM
'High Definition' is marketing bullshit. As has been noted already, its only real technical meaning has to do with display resolution. When used as a descriptor in any other context it's meaningless (do commercials for 'HD audio' bother anyone else?).
+1 for this. Tremulous already has HD, in fact, it works with any resolution if you use the custom mode.
Well this is the issue.
A new rendering engine is nice, I understand that to a vast extent.
For fun I make CG scenes(right now it involves brute force of 10 million polygons for an ocean scene) and try to get them to look realistic.
Anyways I understand on how bump mapping/normals mapping would really help along with displacement mapping combined with an animated texture, stuff like bullet holes and such.
But just like directly contradicting an engineer's philosophy(in some ways, sorta..) we can have a higher polycount and get great FPS with machines that have a $50+ GPU. Efficient? No. Works well within reason? Yes to a decent to good degree.
Quote from: Fox One on November 17, 2010, 09:34:54 PM
Frankly, if you want a higher quality render output, it's not so much the models that need to be changed. Rendering lots of polys is still hard and a waste of time. The client engine really needs to be written to include some form of modern bump mapping (http://en.wikipedia.org/wiki/Bump_mapping) such as parallax (http://en.wikipedia.org/wiki/Parallax_mapping) or normal (http://en.wikipedia.org/wiki/Normal_mapping) mapping so that more complicated geometry can be simulated without significant increases on hardware requirements. Displacement (http://en.wikipedia.org/wiki/Displacement_mapping) mapping would be really nice. Solving graphics ugliness by increasing game model detail is the brute force method and isn't really as effective as other, cheaper (in terms of hardware load) solutions.
Also, none of these improvements are going to look really good unless and until we get dynamic lighting and soft shadows.
'High Definition' is marketing bullshit. As has been noted already, its only real technical meaning has to do with display resolution. When used as a descriptor in any other context it's meaningless (do commercials for 'HD audio' bother anyone else?).
Quote from: jm82792 on November 18, 2010, 04:49:51 AM
But just like directly contradicting an engineer's philosophy(in some ways, sorta..) we can have a higher polycount and get great FPS with machines that have a $50+ GPU. Efficient? No. Works well within reason? Yes to a decent to good degree.
So what you're saying is you want higher-polycount models, and that this has nothing to do with a "HD tremulous".
under HD tremulous you mean just bigger and more detailed textures or what? If you want make 'better' trem with improved visual style and animations 1st remake client side and implement new rendering engine, for example xreal.
Quote from: CATAHA on November 18, 2010, 10:14:20 PM
under HD tremulous you mean just bigger and more detailed textures or what? If you want make 'better' trem with improved visual style and animations 1st remake client side and implement new rendering engine, for example xreal.
So changing the rendering engine will magically make the textures more detailed? A new engine can only do so much, and while it would be nice, treating an XReal port like some sort of silver bullet will get you nowhere. Good engine + shitty textures = shitty graphics. Since modern game graphics place emphasis on a low polycount, almost all the detail is in the textures.
Im not saying new engine is all you need. I said you need it as 1st step! Good huge resolution textures on q3 engine - waste of engine power. If you talking about modern game graphics, then dont forget about modern shaders. They do a lot of work to improve resulting image. If you take hires textures (for example) from Q4 and put them in q3 engine you will never get even half of they 'quality', caus no 'bumping/specular/etc stages implemented. So 1st - upgrade engine, 2nd - improve textures/shaders accordingly to new engine and only in 3rd talk about 'ultimate HD version' of tremulous.
Quote from: CATAHA on November 19, 2010, 12:43:39 AM
So 1st - upgrade engine, 2nd - improve textures/shaders accordingly to new engine and only in 3rd talk about 'ultimate HD version' of tremulous.
Surprisingly I agree with this. +1 for you.
I apologize yet again for being in a tired daze,
thankfully for myself(Like you care lol :) ) the slave labor will end soon.
If we port trem to a new engine(Xreal has lots of bugs from what I hear, bad idea?) we won't have to worry about new textures because people will gain an interest in helping trem and see the ugly bottleneck of crap textures.
Plus materials, trem has the capacity but they are a pain in the butt to utilize and create.
Materials will make the game look really nice if we have more variety and control.
Now a new engine gives us new rendering capacity, in speed because we won't have a decade old engine and
features like bump mapping,(insert here, I could go on forever) ease of use, etc. Plus maybe a less confusing (at least I think) engine.
Porting as everybody knows will be a pain,
and we need a competent leader who coordinates getting trem to the new engine.
Do NOT care about how good it looks initially,
but what it can look like with new textures, models, etc when you have a more capable engine.
If we had the same old trem in a new engine we'd be in good shape because we can bug test, develop,etc and make it more visually appealing.
(I know nothing about porting, I do know 3D and how it works)
Keep in mind bloom, and such look like crap when a newbie uses all the idiot proof features that look bad unless used properly.
Now realistically within the reach or capacity of a single individual(yeah a single guy can port but that's not going to happen) we can create/acquire textures(they have to be 100% free, proper licensing or made yourself. :o) and create a patch/mod/upgrade with a slew of new textures to replace all the default map ones. Most custom maps utilize default textures so many maps will look better.
New models are more complex, not very, but if your going to upgrade their textures don't waste your time, redo the models then texture them.
The complainers can stay on pure servers and use their low res stuff,
better yet the devs will allow us to use "this" mod or, I doubt officially integrate it into trem.
Quote from: jm82792 on November 19, 2010, 04:45:18 AM
we won't have to worry about new textures because people will gain an interest in helping trem and see the ugly bottleneck of crap textures.
Oh, that's ok then.
So, since xreal isn't overly mature, is a touch on the buggy side and has a few compatibility issues, what are you going to use instead?
I have no clue.
There is a website that has been bug fixing and imrpoving ioq3 for awhile.
Nothing special(well it's special but nothing graphically), maybe they will get around to getting it to render better.
There'll probably be something. Other than XReal, I can think of Syntensity and Cube/Sauerbraten off the top of my head. Sauerbraten is the best (IMO) because it's fast and (relatively) lightweight, but translating the maps... ugh. Still, I'm not a developer, what do I know.
If we can get the mesh into it without it being some giant mess then texturing and doing materials should be easy.
Well unless the mapping software(whatever it is) has some quirk.
Quote from: jm82792 on November 19, 2010, 05:59:10 AM
If we can get the mesh into it without it being some giant mess then texturing and doing materials should be easy.
Well unless the mapping software(whatever it is) has some quirk.
That "quirk" is called octree mapping. Sauerbraten uses a completely different map format- maps are made completely of huge arrays of cubes, where the vertices can be pushed and pulled to make non-blocky shapes. The maps can be really high-quality stuff (check out Skycastle, that thing is EPIC), but it's a completely different format.
Well we can make new maps, but the whole concept seems far out and not something I've ever heard of.
I do not see their method as any easier, what you see is what you get mapping seems rather crazy.
Soon grandma will own a quadcore, you'll own a 16 core CPU, and GPU rendering will be norm.
Anybody up for porting trem to the Blender Game Engine ?
It seems kind of arcane at first, but this video (http://www.youtube.com/watch?v=3x5NPVel3dw) should help. A bit. Maybe. In any case, transferring all the maps won't be pretty, but it's definitely doable (especially with the existing maps as blueprints).
It seems like it's effective enough although a higher level of control can be done with plain old modeling.
According to Wikipedia the engine renders fast and from what I see it looks decent.
I know nothing of how to port trem over or quake coding though :)
Whoa. I just realized Aardappel (who created Cube/Sauer) worked on Far Cry. He's got some inside knowledge.
I'll help but I won't be driving anything.
Quote from: jm82792 on November 19, 2010, 06:36:59 AM
Soon grandma will own a quadcore, you'll own a 16 core CPU, and GPU rendering will be norm.
Why this obsession with the future of computing? What matters is what's affordable and current, i don't care about your granny and her quadcore box.
Quote from: Tremulant on November 19, 2010, 09:16:08 AM
Quote from: jm82792 on November 19, 2010, 06:36:59 AM
Soon grandma will own a quadcore, you'll own a 16 core CPU, and GPU rendering will be norm.
Why this obsession with the future of computing? What matters is what's affordable and current, i don't care about your granny and her quadcore box.
Admit it, you can't help but admire her l33tness.
Quote from: Pazuzu on November 19, 2010, 02:47:20 PM
Quote from: Tremulant on November 19, 2010, 09:16:08 AM
Quote from: jm82792 on November 19, 2010, 06:36:59 AM
Soon grandma will own a quadcore, you'll own a 16 core CPU, and GPU rendering will be norm.
Why this obsession with the future of computing? What matters is what's affordable and current, i don't care about your granny and her quadcore box.
Admit it, you can't help but admire her l33tness.
+1 8)
No obsession. The reality is that it's not a bad idea to port trem to a demanding engine if in a year or two it's requirements won't be that much.
Besides my granny doesn't own a computer.
I am trying to attempt a form of sarcastic humor regarding that what we consider good this year is crap the next.
If you ported to the BGE as crazy as it sound,
current PCs can run it fine(very broad example) and in a year or two it will become even more sane sounding.
Quote from: jm82792 on November 19, 2010, 06:33:07 PM
No obsession. The reality is that it's not a bad idea to port trem to a demanding engine if in a year or two it's requirements won't be that much.
What if 1.2 shows up in a year or two?
1.2 is as we can currently judge a gameplay and graphical upgrade that involves manipulating the current assets,
and from what I can understand they are not touching the current engine's code.
Plus they(from what I understand) are not going to touch textures, upgrade models,
well minus the new weapons and the new human model.
None of this stuff is easy but it would be rewarding to port or more realistically upgrade the current assets,
if we upgrade the current assets we can squeeze the engine with some brute force.
Quote from: jm82792 on November 19, 2010, 08:58:37 PM
1.2 is as we can currently judge a gameplay and graphical upgrade that involves manipulating the current assets,
and from what I can understand they are not touching the current engine's code.
Plus they(from what I understand) are not going to touch textures, upgrade models,
well minus the new weapons and the new human model.
None of this stuff is easy but it would be rewarding to port or more realistically upgrade the current assets,
if we upgrade the current assets we can squeeze the engine with some brute force.
My point is that, as the textures and models (for human weapons at least) are already getting upgrades in 1.2, if you do all these changes for 1.1 then it all seems a bit pointless.
About the off comment that magically dumping Trem into XReaL won't improve texture detail:
IOQuake3 appears to use software mipmapping as respect to archaic hardware that wasn't compatible. This makes the textures appear 2 times as blurry as they actually are, especially at a distance. It's not really a big difference, and could probably be implemented into trem without much issue, but I felt it was worth mentioning anyway.
@Fox One
I disagree, shaders such as parallax/displacement have a far more significant impact on framerate, compared to brute-force polygons. The majority of Tremulous' theme is 'tech', that includes metal base matt textures, metallic trims and the like. These shaders weren't made with that purpose in mind, which is why they apply far better to games like Crysis and FarCry, where running shaders on masses of terrain is of course cheaper than ridiculously high polygon counts.
just wanted to say:
GET 1.2 OUT FIRST!
Then work on the engine.
Just wondering why you not talking about '1.2' and 'working on engine'. =)
I am as many other players want 1.2 release. I dont like 1.2, but when it will be released, we can work on mods and stuff to improve it. But its anyway sad to hear, that players just w8i'n 1.2 instead of some 'work'. It means they just want new release in any case, but noting more. =\
Interesting..
IOQuake3 is the bottle neck for textures, although bigger ones can somewhat help.
Quote from: Thorn on November 20, 2010, 01:03:47 PM
About the off comment that magically dumping Trem into XReaL won't improve texture detail:
IOQuake3 appears to use software mipmapping as respect to archaic hardware that wasn't compatible. This makes the textures appear 2 times as blurry as they actually are, especially at a distance. It's not really a big difference, and could probably be implemented into trem without much issue, but I felt it was worth mentioning anyway.
@Fox One
I disagree, shaders such as parallax/displacement have a far more significant impact on framerate, compared to brute-force polygons. The majority of Tremulous' theme is 'tech', that includes metal base matt textures, metallic trims and the like. These shaders weren't made with that purpose in mind, which is why they apply far better to games like Crysis and FarCry, where running shaders on masses of terrain is of course cheaper than ridiculously high polygon counts.
Not true,
It would most likely be trivial for someone experienced with GL to patch in hardware mipmapping (assuming such a patch doesn't already exist). Mipmapping isn't really something to change engine for, and it certainly does not inhibit or 'bottle neck' textures in any way.
How many times do I have to say this? A port to XreaL would not require new assets. It would look no different, but it would use code that is designed to run as much graphics on the GPU as possible, speeding up the game vastly. The enhanced material effects and special model formats can be utilized later.
Quote from: Thorn on November 21, 2010, 02:05:37 AM
Not true,
It would most likely be trivial for someone experienced with GL to patch in hardware mipmapping (assuming such a patch doesn't already exist). Mipmapping isn't really something to change engine for, and it certainly does not inhibit or 'bottle neck' textures in any way.
Well currently it is a bottle neck.
But as I said I do not code. the only coding I do is with MCU's for fun, and it's on the simple side
Heck if it can be fixed great, I'm the bob/joe-schmo/clown that has used Blender for a couple years and knows that realm. A portion of my knowledge is applicable to games, however game engines are very different in many ways related to a 3d package.
Regarding Xreal, I agree don't worry about creating assets for it.
Get it ported(Yeah I don't know anything regarding getting it their.) and the capacity of the new engine should/hopefully drive the demand to create new assets for trem.
Quote from: Odin on November 21, 2010, 03:35:29 AM
How many times do I have to say this? A port to XreaL would not require new assets. It would look no different, but it would use code that is designed to run as much graphics on the GPU as possible, speeding up the game vastly. The enhanced material effects and special model formats can be utilized later.
Because compiling XReaL with the q3acompat flag enabled does not allow it to run on pre-GLSL (6200) hardware. Hence the argument of 'Switch to XReaL - Faster FPS - New Hardware Only!" doesn't make much sense.
Quote from: Thorn on November 21, 2010, 04:14:32 AM
Quote from: Odin on November 21, 2010, 03:35:29 AM
How many times do I have to say this? A port to XreaL would not require new assets. It would look no different, but it would use code that is designed to run as much graphics on the GPU as possible, speeding up the game vastly. The enhanced material effects and special model formats can be utilized later.
Because compiling XReaL with the q3acompat flag enabled does not allow it to run on pre-GLSL (6200) hardware. Hence the argument of 'Switch to XReaL - Faster FPS - New Hardware Only!" doesn't make much sense.
Well some of what yon stated(q3acompat flag) I do not fully understand although I do know what GLSL is and it's sweet, I've toyed with it within blender's BGE.
A $50 GPU should upgrade old PCs correct?
I think people with old pcs should be happy with the old engine,
people with the newer PCs can enjoy the new engine.
It's not like you need a $1000 PC to have GLSL enable GPU.
So you expect devs to maintain netcode compatibility so that users of either version can play together or just to split the game's playerbase in half?
You really think that half of current tremulous players have so old PCs?
Quote from: CATAHA on November 21, 2010, 11:10:18 AM
You really think that half of current tremulous players have so old PCs?
I think a poll might be in order.
Quote from: Pazuzu on November 21, 2010, 03:19:12 PM
Quote from: CATAHA on November 21, 2010, 11:10:18 AM
You really think that half of current tremulous players have so old PCs?
I think a poll might be in order.
I think there was already such a poll, no?
I doubt that even 1/4 of players would actually vote in such poll
Quote from: Thorn on November 21, 2010, 04:14:32 AM
Quote from: Odin on November 21, 2010, 03:35:29 AM
How many times do I have to say this? A port to XreaL would not require new assets. It would look no different, but it would use code that is designed to run as much graphics on the GPU as possible, speeding up the game vastly. The enhanced material effects and special model formats can be utilized later.
Because compiling XReaL with the q3acompat flag enabled does not allow it to run on pre-GLSL (6200) hardware. Hence the argument of 'Switch to XReaL - Faster FPS - New Hardware Only!" doesn't make much sense.
In this day and age, there's really no reason to hold on to hardware pre Geforce 6xxx series. I really think it would be better for everyone if we dropped this mentality of 'doesn't run on old hardware so it is automatically shunned'.
In my opinion, Trem looks fine the way it is. The engine is what needs an upgrade. It doesn't even have to be XreaL. It could just be a random VBO patch(with capability detection so everyone is happy).
From what I hear 1.1 was ported to xreal...
We should get 1.2 to xreal if it's not hard and if the client/server side of things doesn't need to be messed with.
If 1.1 was successfully ported don't you think everyone would play that instead?
Well if it looked identical then it wouldn't :)
I don't know I'll check the website, I think it has to be compiled.
http://xreal-project.net/?page_id=3/Programming/how-to-apply-xreal-engine-to-tremulous/
I'll compile it if I can ...
Quote from: jm82792 on November 23, 2010, 01:39:14 AM
Well if it looked identical then it wouldn't :)
Turn off HDR or other post-processing and it will.
That Goon is too bumpy :-[
Doesn't lighting need to be redone for every existing map?
Yep, and it'll never look 'identical'
1.1 is ported, and they just added bloom and some other effects for the moment, nothing over the top, thorn made bump maps for the only map ported (tremor) and it has a lot of issues compile-wise.... goodluck
Quote from: Tamaru on November 23, 2010, 08:33:00 PM
1.1 is ported, and they just added bloom and some other effects for the moment, nothing over the top
What? It has all the features of XreaL, including but not limited to bloom.
Quote from: Tremulant on November 23, 2010, 07:34:02 PM
Doesn't lighting need to be redone for every existing map?
Not necessarily, if you are thinking that all maps need to be recompiled. I believe the 1.1.0 port can be compiled with compatq3 mode.
Quote from: Tremulant on November 23, 2010, 07:34:02 PM
Doesn't lighting need to be redone for every existing map?
Map recompilation its not so hard work. Even without map source (using .bsp decompilation) you can redone map per day ezily.
Quote from: Odin on November 23, 2010, 09:45:06 PM
Quote from: Tremulant on November 23, 2010, 07:34:02 PM
Doesn't lighting need to be redone for every existing map?
Not necessarily, if you are thinking that all maps need to be recompiled. I believe the 1.1.0 port can be compiled with compatq3 mode.
I'm only basing this assumption on what thorn's told me in the past.
Let me put it this way.
I am willing to help however I can but cannot spend hours and hours learning how to recompile maps :(
I can't keep dumping time into learning things, I've got enough rods in the fire and life is catching up with me.
If anybody wants they should organize a porting team of people who have a basic idea of how to get it over.
I do know a good/decent amount regarding shaders, lighting, animation, texturing, particle systems(little, not much) etc... (Most of the junk you see in Blender, I've been monkeying with most 3D skills for a long time)
Anyways I see this as the golden opportunity to beef up trem.
If we get 1.1 updated then we've accomplished something, fi we get 1.2 that's even better.
Remember we can do lots more than some bloom.
Bump mapping, postpro glare,bloom,whatever(Correct? If so we have a lots of capacity with postpro), better lighting, higher quality textures, higher polycount(correct?) much more than the few easy things that most people compulsively utilize to attempt to show they aren't a newbie ;D
It's like Blender newbies showing off fluid simulations ::)
Wait, slow down a second. Recompiling maps, if they don't require any manual work, sounds like it should be something you can do with scripts. That makes it a lot easier.
Quote from: Pazuzu on November 24, 2010, 03:40:20 PM
Wait, slow down a second. Recompiling maps, if they don't require any manual work, sounds like it should be something you can do with scripts. That makes it a lot easier.
Fixing lighting isn't that easy though.
Quote from: Odin on November 23, 2010, 09:45:06 PM
Quote from: Tremulant on November 23, 2010, 07:34:02 PM
Doesn't lighting need to be redone for every existing map?
Not necessarily, if you are thinking that all maps need to be recompiled. I believe the 1.1.0 port can be compiled with compatq3 mode.
I'm only basing this assumption on what thorn's told me in the past.
Yes, tremulous should be compatible if you compile XreaL with q3acompat, but this does mean not getting any of the features from XReaL's renderer, and at the end of the day it seems a bit pointless. I did mention this before to you, and why it was a bit pointless since the only benefit would be the framerate, and even that can be nullified by the fact that it requires hardware well capable of running the game anyway.
That would probably just be a small project then, compiling the XReaL client in q3acompat with tremulous support, which could likely be distributed as just another optional binary client. Of course, that's purely assumption.
It's pointless if you can't get the features.
I do not code and in the end if we get bump mapping, postpro, MD5's, higher polycount then it's totally worth it.
Basically it sounds good(if we get the features :) ) but I do not know how to get there.
Quote from: Thorn on November 24, 2010, 06:14:34 PM
Quote from: Odin on November 23, 2010, 09:45:06 PM
Quote from: Tremulant on November 23, 2010, 07:34:02 PM
Doesn't lighting need to be redone for every existing map?
Not necessarily, if you are thinking that all maps need to be recompiled. I believe the 1.1.0 port can be compiled with compatq3 mode.
I'm only basing this assumption on what thorn's told me in the past.
Yes, tremulous should be compatible if you compile XreaL with q3acompat, but this does mean not getting any of the features from XReaL's renderer, and at the end of the day it seems a bit pointless. I did mention this before to you, and why it was a bit pointless since the only benefit would be the framerate, and even that can be nullified by the fact that it requires hardware well capable of running the game anyway.
That would probably just be a small project then, compiling the XReaL client in q3acompat with tremulous support, which could likely be distributed as just another optional binary client. Of course, that's purely assumption.
The material keyword(diffuseMap, normalMap, etc) support can be just re-enabled after the fact. I think it's switched off with a simple #ifdef.
Hrm.
Well I can read up on Doom3 shaders.
Give the shader the textures, generate bump and spec maps then see what happens.
The maps are created using a modded form of radient right?
Basically I want to get it to work, utilize the new shaders, get a demo map and go from there.
When it's that far I can try to get a MD5 human character into the engine and get some tests to see how well MD5 is compared to MD3. The character would just be a simplistic rig to get the idea across.
I do not know if MD5 uses a animation CFG to tell the engine what frames and where,
I'll look it up and see.
I'm used to doing stills and not worrying about performance, but I will continue to read and get some understanding involving quake 3 and Xreal because I'd love to see something happen regarding a port.
Yo. I'm in that kind of mood again and so decided to do some concept work for a higher detail goon. My suggestion is that higher details beg for a new more interesting texture. Let me know if you like the direction I've taken and should continue it!
(http://img9.imageshack.us/img9/4748/dragoonnewleg.png)
Quote from: Nux on November 25, 2010, 11:00:34 PM
Yo. I'm in that kind of mood again and so decided to do some concept work for a higher detail goon. My suggestion is that higher details beg for a new more interesting texture. Let me know if you like the direction I've taken and should continue it!
[img]
I do indeed like it, except for the odd purple spots in the middle of the leg.
Is that kind of a texture even possible to have in such an outdated engine though?
Scale the textures up then brush them over to make them look better is what you can do.
I am downloading Xreal, I know nothing of compiling so this will be fun.
My friend knows much more about Quake3 than I do and he is trying to figure it out.
But the documentation isn't there for XReal..........
High texture resolution isnt real solution. Without good engine its just waste of memory/cputime. Old engines crop and simplify textures a bit. Im not coder, but seems its fact or something. Btw, you dont need very high-res textures for natural look. I think lowres texture with proper bump/specular maps, advanced lighting stage and post-processing gonna look like much better then just plain high-res texture.
P.S. Ye, i know that some texture sets have high quality textures, which are good without post-processing. But its exception, not rule. Not so many texture sets have such outstanding quality. And ye, just imagine what amazing result can give such textures after applying of bump/post/specular/etc stages... =}
Quote from: Tremulant on November 26, 2010, 03:14:43 AM
Quote from: CATAHA on November 26, 2010, 02:48:05 AM
Im not coder, but seems its fact or something.
Wut for this quote? You agree with this, disagree or forcing me ask our mod coder for details? =D
I can be wrong in some details, but i still think that mainly i was correct.
Every engine from Quake I to Crysis uses downscaled textures. If you load a 1024x1024 texture, it compute 512x512, 256x256, ..., 1x1 textures called mipmaps. Then when an object is rendered it picks the texture where the resolution best matches the screen resolution. I.e. if your 1024x1024 texture appears on a 4x4 quad on the screen, it will automatically use the 4x4 texture.
This means that you can see the super-high-res textures only when you're sufficiently close. You can use the switch /r_colorMipLevels 1 in Tremulous to see the effect. All downscaled textures will be coloured differently, only the base texture keeps the original colour.
Old engines may have problems with texture sizes that are not powers of two and rescale them, which blurs the textures a bit, but most textures have power of two sizes, so that's not a big problem.
If you only want to add some noise to the textures to make them less boring at close views, you can use detail textures, i.e. you use the mid-res textures that you have now and add a noise texture in a second renderer pass. The noise texture can be repeated over the surface, so it does not need to be big for high resolution.
Not to mention that the Quake 3 engine builds mipmaps in software, which makes worse results than the driver solution. (iirc)
Quote from: gimhael on November 26, 2010, 07:16:06 AM
If you only want to add some noise to the textures to make them less boring at close views, you can use detail textures, i.e. you use the mid-res textures that you have now and add a noise texture in a second renderer pass. The noise texture can be repeated over the surface, so it does not need to be big for high resolution.
This is typically frowned upon by the Tremulous community(I have first-hand experience with this subject). Since r_detailtextures is defaulted to 1, and there is no menu option for it, nobody seems to know that a detail texture is even being used and don't realize they can turn if off with r_detailtextures 0 to gain their lost fps back.
Interesting. I'd almost want to read a quake 3 engine manual that wouldn't totally bore me.
The only rendering I've done is with Maya and Blender so this concept is new to me.
I think all OpenGL drivers use a simple box filter for mipmap generation. The feature was introduced with FBOs to generate mipmaps on a texture that you just rendered to. So the focus is on speed not quality. What the hardware probably does is gamma compensation, the quake engine does not do this, so the low mipmaps are usually a bit too bright.
To get highest quality mipmaps you have to generate them offline e.g. with NVIDIA's texture tools or AMD's compressonator. In that case you can also use s3tc compression which reduces images by 1:8 with very little loss of quality (i.e. you can double the resolution in both directions and still have only half the size of the same image in a TGA). The advantage of s3tc is that is kept compressed in graphics memory on pretty much every card since Voodoo3 times and so uses less texture ram/cache than e.g. a jpeg.
Unfortunately the common format for these textures is the .DDS file format and ioquake3 lacks a loader for them. I'm currently working on a patch to support this format, maybe they'll include it in the engine when it's done (I can already load compressed textures and mipmaps, but it fails to load uncompressed dds formats).
I am the monkey who pushes the buttons and uses the packages but doesn't develop them :(
A patch that improves the textures sounds like a good idea.
Quote from: gimhael on November 26, 2010, 07:16:06 AM
If you only want to add some noise to the textures to make them less boring at close views, you can use detail textures, i.e. you use the mid-res textures that you have now and add a noise texture in a second renderer pass. The noise texture can be repeated over the surface, so it does not need to be big for high resolution.
Is this the kind of thing that was going on in serious sam when the camera got up close to an object? It did quite a good job on stone textures and the like.
Quote from: Tremulant on November 26, 2010, 12:45:31 PM
Is this the kind of thing that was going on in serious sam when the camera got up close to an object? It did quite a good job on stone textures and the like.
Example screenshot: (http://lh6.ggpht.com/_hLklTmrBczA/TPAjBbN4XQI/AAAAAAAAADc/y9Z3wFyeI3s/s800/shot0008.jpg)
This shows a small 128x128 noise texture with horizontal blur that I made in 2 minutes added to the left texture. The shader scales the detail texture by a factor of 9, so that it has an effective resolution of 1152x1152 pixels:
textures/utcs/eq2_bmtl_02
{
{
map textures/utcs/eq2_bmtl_02.jpg
}
{
map $lightmap
tcgen lightmap
blendfunc filter
}
{
detail
map textures/utcs/detail.jpg
tcmod scale 9 9
blendfunc GL_DST_COLOR GL_ONE
rgbGen const ( 0.66 0.66 0.66 )
}
}
The current engine can only draw two textures in a single pass, so that this change requires an extra pass, i.e. it will reduce FPS. However it can be disabled for old chips with /r_detailtextures 0.
Very interesting.
Quote from: Nux on November 25, 2010, 11:00:34 PM
Yo. I'm in that kind of mood again and so decided to do some concept work for a higher detail goon. My suggestion is that higher details beg for a new more interesting texture. Let me know if you like the direction I've taken and should continue it!
(http://img9.imageshack.us/img9/4748/dragoonnewleg.png)
NICE!
Nice work Nux! :o
That leg looks there is *some* muscle in it, not just a solid stick leg.
a shadow dragoon??
Love it. +1
That looks great, please continue!
This is not HD graphic but it is ATCS map in better HD capable engine (Unreal Engine 3). Map is 99% finished, some energy fence and skybox missing yet. I rebuilded it piece by piece. Textures are ugly ATCS default without any effects.
(http://img257.imageshack.us/img257/9544/65268520.jpg)
(http://img33.imageshack.us/img33/8471/59991917.jpg)
(http://img405.imageshack.us/img405/1307/33417446.jpg)
(http://img257.imageshack.us/img257/8346/12731932.jpg)
Heh, that's awesome.
hey lonly, you just saw real development on tremulous 8)
cool, better shadows are one of the things trem needs...
Wasn't too impressed at first. Then I saw the second screenshot.
Can has new engine nao plzkthx?
Quote from: rotacak on November 27, 2010, 06:05:49 PM
This is not HD graphic but it is ATCS map in better HD capable engine (Unreal Engine 3). Map is 99% finished, some energy fence and skybox missing yet. I rebuilded it piece by piece. Textures are ugly ATCS default without any effects.
(http://img33.imageshack.us/img33/8471/59991917.jpg)
I didn't know you can run quake 3 mod on Unreal engine 3 ?!
Unreal Engine is really cool but can you give us it for free ? That's the question.
It's really cool BUT ... you didn't use bump maps.
Anyway that's awesome and it's a good beginning full of sucess.
Quote from: freezway on November 27, 2010, 07:33:16 PM
cool, better shadows are one of the things trem needs...
derp
lightmapscale <float>
The big difference here is, Q3map2 raytraces the lightmaps. UE3 bakes shadowmaps into lightmaps(iirc).
If anyone is wondering, the huge contrast in light/shadows in outside area is due to no skylight, just the sun. Also, the direction of the sun is much higher, and the sun & some of the lights have slightly different color/intensity. It'll look a lot more bland/like the atcs we know once those differences have been removed :P
still looks better
Quote from: gimhael on November 26, 2010, 09:46:15 PM
Example screenshot: (http://lh6.ggpht.com/_hLklTmrBczA/TPAjBbN4XQI/AAAAAAAAADc/y9Z3wFyeI3s/s800/shot0008.jpg)
This shows a small 128x128 noise texture with horizontal blur that I made in 2 minutes added to the left texture. The shader scales the detail texture by a factor of 9, so that it has an effective resolution of 1152x1152 pixels
This seems to have some potential.
as for UE3, wow, what a spectacular waste of effort, i guess distant textures look a bit clearer but that's about it(granted that's no surprise considering the same old assets are in use). Are you getting a massively improved framerate?
Unless its free, UE3 is a waste of time, even if it makes you computer shit lollipops.
XReal seems most realistic in getting it there.
From my testing of XReal it looks decent and with a some brain cells being placed into a good map and good materials then we will be set.
Quote from: harraps on November 27, 2010, 10:06:48 PM
Quote from: rotacak on November 27, 2010, 06:05:49 PM
This is not HD graphic but it is ATCS map in better HD capable engine (Unreal Engine 3). Map is 99% finished, some energy fence and skybox missing yet. I rebuilded it piece by piece. Textures are ugly ATCS default without any effects.
I didn't know you can run quake 3 mod on Unreal engine 3 ?!
Unreal Engine is really cool but can you give us it for free ? That's the question.
It's really cool BUT ... you didn't use bump maps.
Anyway that's awesome and it's a good beginning full of sucess.
Unreal Engine 3 is free and you cant run there Q3 mod. It need to remake tremulous from begining. I not used bumpmaps because I want to only make it work like old tremulous - then I can start to improve. But I dont know If I am able to finish it and now I not have even time for it.
UE3 can do nice results: http://www.youtube.com/watch?v=MGf0oGGGQqQ
So, rotacak, since everyone wants the xreal port for better FPS on modern hardware(well, not everyone but a number of this lot), how does your framerate compare between the UE3 trem clone and standard trem at the same res, is it a dramatic improvement?
Quote from: freezway on November 28, 2010, 03:58:54 AM
Unless its free, UE3 is a waste of time, even if it makes you computer shit lollipops.
His point is that Tremulous looks better on other engines.
If you want, I'll see if I can make some normal maps for ATCS textures. Then we can see how it would look with bump-mapping.
Been there, pretty mediocre. Normalmaps + Low resolution textures do not work well.
So I downloaded basically the whole SVN "thing" (yes I don't know much, and I need to read more. What a joy) a gig and a half in all.
From what I can understand it needs to be (eventually) compiled although it plays uncompiled.
There is a tremulous branch although I am not sure how to get it to work and I'm trying to understand the structure of XReal. I do not know where it would see mods, it could be as as easy as putting the trem patch/mod in the correct place since it RUNS with XReal and is made to work. My friend knows more than I do but both of us don't know much regarding development., but with enough reading anything is possible.
If we can get the mod to work and everything checks out then we can redo a map(materials, etc),
high res textures with proper licensing (that will be easy, NOT) and finally see what happens then utilize as much of XReal's features while making everything looking good.
From what I can see 2 maps are playable with XReal, if I get the branch to work
(I'm emailing a dev in a minute, hopefully I'm not wasting his time) then we have 2 maps to see how they work for XReal and why. dissecting something that works is always better than nothing)
Remaking assets(Aliens humans etc) is something you shouldn't be able to mess up and is rather straight forward,
especially since it's MD5's :) But being straight forward doesn't mean it won't take time.
Quote from: Tremulant on November 28, 2010, 12:32:34 PM
So, rotacak, since everyone wants the xreal port for better FPS on modern hardware(well, not everyone but a number of this lot), how does your framerate compare between the UE3 trem clone and standard trem at the same res, is it a dramatic improvement?
Well, everyone want xreal port because it is "easy" and multiplatform. But how I see, xreal have no physics engine and would be nice to have some new features with new engine than only graphic - like destructive enviroment, clothes, vehicles, physics buildables (you can throw barrel on dretch and crush him etc.). And xreal community is very small (look at their forum), same with new releases.
Comparing framerate will be difficult because it depends on map.
Well you can integrate Bullet into it somehow.
Honestly physics are nice but your getting far too picky and separated from the current reality of what we have to work with.
I not saying that I want to make immediately vehicles etc. :) But that are possibilities. Everything is already inside this engine.
Quote from: rotacak on November 28, 2010, 07:12:51 PM
Comparing framerate will be difficult because it depends on map.
Go ahead and use ATCS for the comparison...
Quote from: Pazuzu on November 28, 2010, 05:06:44 PM
Quote from: freezway on November 28, 2010, 03:58:54 AM
Unless its free, UE3 is a waste of time, even if it makes you computer shit lollipops.
His point is that Tremulous looks better on other engines.
If you want, I'll see if I can make some normal maps for ATCS textures. Then we can see how it would look with bump-mapping.
Can I give you an advice?
Try to use original texture and turn them in black and white and then in normal maps with the gimp
before doing hard work. I think it could help you.
Quote from: harraps on November 28, 2010, 11:05:51 PM
Quote from: Pazuzu on November 28, 2010, 05:06:44 PM
Quote from: freezway on November 28, 2010, 03:58:54 AM
Unless its free, UE3 is a waste of time, even if it makes you computer shit lollipops.
His point is that Tremulous looks better on other engines.
If you want, I'll see if I can make some normal maps for ATCS textures. Then we can see how it would look with bump-mapping.
Can I give you an advice?
Try to use original texture and turn them in black and white and then in normal maps with the gimp
1) I know.
2) Trust me, I know. The only other real way to make normal maps would be to build them with a modeling program, then bake and export them, and that would take forever.
3) Normal maps are purple, not black and white.
Quote from: Tremulant on November 28, 2010, 09:30:41 PM
Quote from: rotacak on November 28, 2010, 07:12:51 PM
Comparing framerate will be difficult because it depends on map.
Go ahead and use ATCS for the comparison...
But that will be Q3 vs U3, not xreal VS U3.
Anyway (1920x1080, fullscreen, one player):
U3: 180 fps (and I forgot to turn off motion blur)
Q3 Tremulous: 600 fps
Q3 Tremulous (def. layout): 450 fps
Q3 Tremulous (def. layout + 10 turrets): 330 fps
I can try to simulate turrets on U3 later.
Motion blur makes a lot of difference. Try it with the exact same graphic options (ie same filtering, no blur, same texture quality).
I think comparing Q3 with U3 pointless, just because those engines have different possibilities. If you talking only about speed, then Wolfensten3D is our choice for sure. But good project need not only speed, it need good balance between Speed and Quality.
Quote from: rotacak on November 28, 2010, 11:30:50 PM
But that will be Q3 vs U3, not xreal VS U3.
That's quite alright, it's a test of a modern 3D engine versus the antiquated ioq3, choking on its various bottlenecks, we don't need a direct comparison with xreal here, afterall the main reason people seem to want a quick and dirty port to xreal is for the much needed potential performance gain on those machines with modern graphics cards(this may not make much sense but hey).
cataha, are you seeing much difference at this stage, quality wise?
Quote from: Tremulant on November 29, 2010, 12:08:09 AM
cataha, are you seeing much difference at this stage, quality wise?
Yes, even in editor:
Quote from: rotacak on November 27, 2010, 06:05:49 PMI rebuilded it piece by piece. Textures are ugly ATCS default without any effects.
(http://img257.imageshack.us/img257/9544/65268520.jpg)
Look at model shadows. In Q3/Trem we have no proper shadows from models. Actually we cant compare those two engines properly, they base and possibilities too different.
A dretch casting a shadow is a massive visual improvement that makes framerate comparison meaningless?
this is in UDK, making it completely free and ope to whoever wants it.
and ye, bumpmaps would be nice, maybe a whole do-over of a map in UDK
Q3 and U3 shadow processing very different. U3 shadows placed with effects and on proper brushes. Q3 even have no real shadows, just closer 'simulation'. Thats difference. And im not talking about world shadows, Q3 have static one.
Anyway... dont look at pictures, look at code. How many stages in shaders, etc. If you wanna real comparsion - get Q3 fps, then make same scene in U3 and include more and more effects and improvements till fps drop to Q3 value. Compare screenshots then to feel real difference.
All i want is a comparison of framerates for two scenes that look similar enough, don't care about code or possibilities for increased awesomeness.
You're describing UDK as "free and ope[n]", are you sure it tallies with popular definitions of free and open in use around here?
Well, than i gonna take off, because 'similar enough' too judgmental for me. Especially when we talking about realtime-render engine, not about photos. With ur judgement statements Q3 obviously better than U3, because it faster. No offence, its fact.
P.S. I still can be wrong if U3 optimized for modern videocards or something else. But i bet on Q3. =}
But hadn't the zomg xreal crowd already decided that a port to xreal would give a massive performance boost from simply taking advantage of modern gpu features? surely UE3 will have a similar base advantage before it starts wasting time on pretty effects that we can't really see?
Quote from: Tremulant on November 29, 2010, 02:08:13 AM
But hadn't the zomg xreal crowd already decided that a port to xreal would give a massive performance boost from simply taking advantage of modern gpu features? surely UE3 will have a similar base advantage before it starts wasting time on pretty effects that we can't really see?
That reminds me, what about Sauerbraten? A port would take forever, but I'd really want to see an ATCS-versus-ATCS comparison for Sauer.
EDIT: rotacak, how are you getting 600? Isn't there a maximum framerate in Tremulous, and if there is, how do you disable it?
Quote from: Tremulant on November 29, 2010, 02:08:13 AM
But hadn't the zomg xreal crowd already decided that a port to xreal would give a massive performance boost from simply taking advantage of modern gpu features? surely UE3 will have a similar base advantage before it starts wasting time on pretty effects that we can't really see?
So we taling about U3 vs Q3 or about XReal vs Q3? If about XReal vs Q3, then obviously XReal pwn. But dont compare XReal with U3, because U3 more wide-purpose engine, than Xreal, which was created especially for Quake-like shooter. It have no those unnecessary features, that we dont need in trem (face animation, special plants/trees processing, cloth animation, etc)
what? so when UE3's not performing any of those extra special effects it still suffers as a result of supporting the option for them? wow, it must be very poorly put together. Hey, or are we back onto pointless speculation again?
Quote from: CATAHA on November 29, 2010, 02:27:24 AM
Quote from: Tremulant on November 29, 2010, 02:08:13 AM
But hadn't the zomg xreal crowd already decided that a port to xreal would give a massive performance boost from simply taking advantage of modern gpu features? surely UE3 will have a similar base advantage before it starts wasting time on pretty effects that we can't really see?
So we taling about U3 vs Q3 or about XReal vs Q3? If about XReal vs Q3, then obviously XReal pwn. But dont compare XReal with U3, because U3 more wide-purpose engine, than Xreal, which was created especially for Quake-like shooter. It have no those unnecessary features, that we dont need in trem (face animation, special plants/trees processing, cloth animation, etc)
The biggest issue is this.
Porting is a pain, and getting Trem to XReal is a hard thing to do for people who have a life and a job.
Take something that would need a total recode such as U3 and the chance of porting plummets to almost nothing.
Quote from: Pazuzu on November 29, 2010, 02:10:56 AM
Quote from: Tremulant on November 29, 2010, 02:08:13 AM
But hadn't the zomg xreal crowd already decided that a port to xreal would give a massive performance boost from simply taking advantage of modern gpu features? surely UE3 will have a similar base advantage before it starts wasting time on pretty effects that we can't really see?
That reminds me, what about Sauerbraten? A port would take forever, but I'd really want to see an ATCS-versus-ATCS comparison for Sauer.
EDIT: rotacak, how are you getting 600? Isn't there a maximum framerate in Tremulous, and if there is, how do you disable it?
/com_maxfps is the cvar you want, but you lag out if u set it to 0 (unlim)
Every few months there's a thread just like this, which makes me somewhat hoping for an XreaL port of Trem. Every one of these threads ends disappointingly with nothing.
Until someone(with actual knowledge in how this stuff works) does something to make that a reality, you're wasting your time.
Yes I know what you mean.
I'm a want to be 3D artists that's decent at some things.
I'm trying to prod around and see what happens.
Although I am personally trying to get it off the ground but I am far from being any form of a software developer.
The XReal status is this.
There is a patch, it works, I need to somehow compile it.
Many people have compiled it and I have an idea of how but I'm not sure exactly how.
When it's compiled we can expand it since from what I can understand it's bare bones.
Someone who knows software development thinks I'm an idiot right now and could compile it in 1 minute.
You get the idea.
Quote from: jm82792 on November 29, 2010, 04:18:07 AM
The biggest issue is this.
Porting is a pain, and getting Trem to XReal is a hard thing to do for people who have a life and a job.
Take something that would need a total recode such as U3 and the chance of porting plummets to almost nothing.
moving to U3 could be wouldnt be that much more work then xreal because it easier to dev.
waht im saying is you could port the current maps and models to u3 and plug in the game play manually
Quote from: Odin on November 29, 2010, 06:50:27 AM
Every few months there's a thread just like this, which makes me somewhat hoping for an XreaL port of Trem. Every one of these threads ends disappointingly with nothing.
Until someone(with actual knowledge in how this stuff works) does something to make that a reality, you're wasting your time.
Well there have been not only threads but also projects to port Trem over to Xreal, i know of the Tremfusion attempt to include a Xreal-based renderer and the Xtr3m project.
I think the big problem with this kind of project is that they lack a clearly defined goal. Usually they start with 'we want some nicer graphics', but then the want-to-have list is expanded (correct physics, vehicles, scriptable maps, game modes, new weapons/classes, whatever) until the project is so big that it is completely impossible to do with the available people.
Apart from the development aspect I think a new engine at this time will split the already small community of Tremulous players again. Some think that after 1.2 is released all the 1.1 players/server will migrate to 1.2, but I'm not so sure. If you now add a new engine with new models/maps etc, this means that you will also have servers for the new maps and servers for the old maps and players need the right client for the right server.
gimhael: first goal should be just port tremulous to other engine without anything else. After that is possible trying to add vehicles etc :) I think that porting tremulous or even completely rewrite tremulous for new engine is one or two months work for good programer.
Geez, vehicles?
Quote from: Pazuzu on November 28, 2010, 05:06:44 PM
If you want, I'll see if I can make some normal maps for ATCS textures. Then we can see how it would look with bump-mapping.
Make some then, I want to see it too :)
Quote from: gimhael on November 29, 2010, 10:06:58 AM
Apart from the development aspect I think a new engine at this time will split the already small community of Tremulous players again. Some think that after 1.2 is released all the 1.1 players/server will migrate to 1.2, but I'm not so sure. If you now add a new engine with new models/maps etc, this means that you will also have servers for the new maps and servers for the old maps and players need the right client for the right server.
Not only split, but expand too and attract new players. For expample many old trem players in russian community switching to Natural Selection 2, and its just because of outdated Trem engine. Im sure that while 1.1 master server is up there gonna be players in 1.1 (im one of them). Only exception - 1.2 mod for '1.1 gameplay copy', when it will come out we will switch to 1.2 (our clan still w8 for full 1.2 release to work on this mod). When we talking about new engine, we talking about total upgrade, not about fork in development, so no global split.
Quote from: Repatition on November 29, 2010, 07:23:02 AM
Quote from: jm82792 on November 29, 2010, 04:18:07 AM
The biggest issue is this.
Porting is a pain, and getting Trem to XReal is a hard thing to do for people who have a life and a job.
Take something that would need a total recode such as U3 and the chance of porting plummets to almost nothing.
moving to U3 could be wouldnt be that much more work then xreal because it easier to dev.
waht im saying is you could port the current maps and models to u3 and plug in the game play manually
How, exactly, is it "easier to dev"? Is there some sort of script to convert Trem maps to U3's format? IIRC, U3 was already ruled out anyway because of licensing issues (U3 is closed-source, Tremulous is GPL'd). XReal (along with Sauerbraten) is open-source, but you'd probably have to go through the same time-consuming processes no matter which engine you choose.
Another fps test for U3:
1920x1080, view from reactor place
10 turrets = 165 fps
200 turrets = 70 fps
Lowest fps from middle of room = 33 fps
One turret = 508 tris, 473 verts.
Computer: AMD Athlon II X3 440, geforce gtx 460 768 MB
(http://img535.imageshack.us/img535/2272/45876433.jpg)
what am i seeing, rotacak?
Are you sure you're using the exact same settings for U3Trem and ioTrem (you said something about blur earlier)? Because I don't remember Tremulous having models of enormous toads with bombs stuck in their asses.
Quote from: Pazuzu on November 29, 2010, 09:21:15 PM
I don't remember Tremulous having models of enormous toads with bombs stuck in their asses.
Oh come now, there's bound to be a mod for that.
Quote from: Pazuzu on November 29, 2010, 09:21:15 PM
Are you sure you're using the exact same settings for U3Trem and ioTrem (you said something about blur earlier)? Because I don't remember Tremulous having models of enormous toads with bombs stuck in their asses.
It's the updated 1.2 model silly.
Quote from: CreatureofHell on November 29, 2010, 09:57:59 PM
It's the updated 1.2 model silly.
When did trem get a model silly?
Quote from: swamp-cecil on November 29, 2010, 08:39:53 PM
what am i seeing, rotacak?
You see 200 "turrets" inside base.
Pazuzu: exact settings? Dunno, similar. There are very much options that arent in Q3. That turrets are also physics objects, they can fall, rotate and everyone casting shadows. I turned off blur, but seems like it have no impact in this engine or only about 5 fps in empty map (there is also more types of blur and many options). And that is not toads :) but guns from top of one vehicle. I don't know how many turrets can fit into base in tremulous, but hardly 200, because these are smaller and even that you almost cant walk in/out base.
I think if we make a tremulous with Xreal engine, it will be the same game but with new graphic.
But if we make a trem with UDK, we should try to make something different.
For example: vehicles, opened area, new aliens, and so much more that we are able to do with Unreal Engine 3.
Currently I'm writing something like a big list of all the stuff to a game project I called " Tremulous Reload" for U3.
Maybe it will be done, maybe not, but I'm sure the idea I get is not bad.
Finally I will give you the stuff list when it will be complete.
I think to keep it realistic since tremulous has a very good gameplay we should do XReal and ignore other engines that need a total rewrite.
Quote from: jm82792 on November 30, 2010, 10:41:59 PM
I think to keep it realistic since tremulous has a very good gameplay we should do XReal and ignore other engines that need a total rewrite.
Seconded. I keep bringing up Sauerbraten, but since there's no easy way to convert the maps (f**king octrees, how do they work?), it probably won't happen.
Octrees sound totally ridiculous because we have a massive base of maps that can easily be converted to XReal.
I really ope you guys are talking about 1.3/2.0... not gunna happen in 1.2.
It can be done *right now*. People just lack the knowledge or will to do it.
The only thing really different about xreal compared to ioquake3 is that you're forced to use libs instead of the qvm system(it was ripped out).
Well as I've stated I know a section of how to get it over but not much.
I am hoping to understand how along with a friend of mine whom has more Quake 3 knowledge than I do,
and he will hopefully be emailing the developer soon regarding this quest.
As I've stated before once it's over then the rest is hard to screw up.
@rotacak: Tremulous can render lots of objects too, here are 80 fps with lots of teslas in transit (on AMD 5770):
(http://img560.imageshack.us/img560/3644/shot0000nc.jpg)
The engine was running in SMP mode, so the renderer and cgame could work in parallel. In my experience it is the cgame that slows down the engine when there are lots of objects around.
Coincidally, switching to blaster improves the framerate a little bit:
(http://img148.imageshack.us/img148/5813/shot000101.jpg)
gimhael: that hp bars consuming lot of fps, I know that from R Funserver CZ. That is one reason why hp bars are turned of (on this server) when you placing buildable, othervise it is often choppy. What CPU you using?
Porting should not be thought of as better FPS but good to great FPS with better engine capabilities (rendering etc)
UDK isnt open its only free(i saw a post a few pages back asking if its free and open) but it would make a good choice if you can live with the engine not being open source. maybe if there's enough interest a team of players(no trem devs since they gotta get 1.2 out the door now hurry up) could knock up a playable demo in udk
EDIT: actually UDK is ut3 so it has no linux version so thats a no go back to xreal or maybe doom3
Besides you'd have to rewrite the code for U3.
All you need for cloth is Bullet, if someone will go about integrating into XReal.
(I don't know how hard it is to get bullet into XReal)
I use bullet with Blender, softbodies work as cloth, jello, whatever.
Bullet does ridged bodies, plus some other features.
Plus Bullet is open source.
Quote from: jm82792 on December 01, 2010, 05:32:11 PM
Besides you'd have to rewrite the code for U3.
All you need for cloth is Bullet, if someone will go about integrating into XReal.
(I don't know how hard it is to get bullet into XReal)
I use bullet with Blender, softbodies work as cloth, jello, whatever.
Bullet does ridged bodies, plus some other features.
Plus Bullet is open source.
Soft bodies would be nice, but what would they do to the framerate? I'd imagine the vert count would skyrocket.
Do we really need clothes in trem in first place?
This has become quite a funny thread. Seven pages of speculation, "what if", daydreaming, totally unrealistic goals and needless pondering.
Hasn't anyone learned from the previous hundred threads? Doesn't anyone view this as really pointless since even thinking of it requires a) 1.2 to be released, and even then it is a highly unrealistic thing to really happen since there isn't any hint whatsoever of b) an actual team seriously committed to doing it.
Seriously, nothing else than poor screenshots with ATCS textures is going to happen out of this thread. At least you could stop rushing in prematurely, and wait for 1.2 to be released. Then there's an actual possibility to think what actually needs to be and could be changed for the next version and what tools there are to attain the goals. Thinking how stuff like vehicles would be so cool isn't really getting anywhere.
Quote from: Meisseli on December 01, 2010, 06:36:53 PM
This has become quite a funny thread. Seven pages of speculation, "what if", daydreaming, totally unrealistic goals and needless pondering.
Hasn't anyone learned from the previous hundred threads? Doesn't anyone view this as really pointless...
Like "flying alien" for example? There was many threads about flying alien and almost all was spammed by users like you with text "go code it" "never happen" etc.
I like this discussion, because it is about something and not pointless. When I started topic about U3 engine, it was spammed and moved to offtopic or some shit by DEVS.
So tell me, what we should discuss here instead of this?
Quote from: Meisseli on December 01, 2010, 06:36:53 PM
This has become quite a funny thread. Seven pages of speculation, "what if", daydreaming, totally unrealistic goals and needless pondering.
Hasn't anyone learned from the previous hundred threads? Doesn't anyone view this as really pointless since even thinking of it requires a) 1.2 to be released, and even then it is a highly unrealistic thing to really happen since there isn't any hint whatsoever of b) an actual team seriously committed to doing it.
Seriously, nothing else than poor screenshots with ATCS textures is going to happen out of this thread. At least you could stop rushing in prematurely, and wait for 1.2 to be released. Then there's an actual possibility to think what actually needs to be and could be changed for the next version and what tools there are to attain the goals. Thinking how stuff like vehicles would be so cool isn't really getting anywhere.
Quoted for truth. 1.2 is what the developers are working on now, and without their help, none of these changes will stand a chance. Everyone suggesting huge changes (porting for 1.2? really?), but apologetically ending your posts with an "Oh sorry, I can't do it, I don't have time", here's something you
can do:
Find/make sounds so 1.2 can finally get out the door.And while you flame me over this, I'll be in abSynth, making noises.
If you all really want to work on porting Tremulous to XReal, you should probably talk with some of these folks first:
Amanieu and Ender of the Tremfusion dev team (http://www.tremfusion.net/team/). Amanieu knows quite a lot about the technical side of Tremulous, but is often unavailable. Ender was working specifically on getting MD5 models working (http://www.tremfusion.net/forum/viewtopic.php?f=2&t=52).
Thorn of the Unvanquished (http://unvanquished.net/forum/index.php) mod project. He was working on adjusting Tremor to use XReal's features (http://unvanquished.net/forum/index.php?topic=218.0) (the images are missing, but they looked nice; maybe if you talk to him he can show you).
Amanieu and Thorn can be found on freenode (http://freenode.net/) in the #unvanquished channel, and if they're not available someone there can probably point you in the right direction.
Learn everything you can and avoid reinventing the wheel if possible.
Quote from: Fox One on December 07, 2010, 08:42:01 PM
Amanieu and Thorn can be found on freenode (http://freenode.net/) in the #unvanquished channel, and if they're not available someone there can probably point you in the right direction.
Thorn can't. Better find him in #tremulous or #xreal.
afaik Amanieu now in UrT dev team and not working on Tremulous anymore.
Quote from: Meisseli on November 13, 2010, 11:36:49 AM
I think only the armoured, shell part of the head and mouth with those fangs look good with that effect of yours.
The rest of the goon looks pretty terrible, especially feet.
Armour: looks like he's infected with osteoporosis.
Legs: Looks like they penetrate something of some kind. Front legs are meant to pounce.
Over all it looks good. Looks like it could replace the 1.2 models XD
i could maybe help?
It's far from easy to accomplish even with good models.
Just a few things I'd like to point out in this thread:
Tremulous is already ported to Xreal and works.
In my experience, the ONLY thing that did not work was the HUD.
The other thing I'd like to point out is that Sauerbraten's engine is terrible and you should stop suggesting it.
Have you ever tried to play a custom map in Sauerbraten? If you don't have the map, you can essentially choose to play on whatever map you want to and still shoot people from vantage points they don't have. You can kill people from a map they're not playing.
If that's not a bad engine, I don't know what is.
Quote from: KillerWhale on January 09, 2011, 10:27:20 PM
Just a few things I'd like to point out in this thread:
Tremulous is already ported to Xreal and works.
In my experience, the ONLY thing that did not work was the HUD.
The other thing I'd like to point out is that Sauerbraten's engine is terrible and you should stop suggesting it.
Have you ever tried to play a custom map in Sauerbraten? If you don't have the map, you can essentially choose to play on whatever map you want to and still shoot people from vantage points they don't have. You can kill people from a map they're not playing.
If that's not a bad engine, I don't know what is.
Even though I don't support a Sauerbraten port, this issue needs to be cleared up. That's a bug in the networking code, which would probably be fixed at some point anyway to make it work with Tremulous. I'm not sure if that's even part of the
engine, so much as the FPS demo included with it.
I haven't heard anything about Tremulous working on XReal. If it does, that's awesome, but I want a demo.
Dunno about demo, but i saw some screenshots of this try before. Even on this forum. Tremor (those was ugly enough) and ATCS (very hot!). Sad, but seems those links are dead right now. =\
In any case devs dont wanna use that port, tremfusion features or something else. =(
What we have.
An old engine, old information tailored to old computers.
You will get some improvement with a new one but not much with old information/entities.
If we have a new engine it will(probably) create a void and drive demand to create new entities for the new engine.
And you can't expect new entities and whatever else in a timely manner from the current dev team. Most are busy with actual work (or so I hear :P), and developing for trem is a side thing.
If there was a NEW engine that supported MD5's or something that good then I'd be making some of them.
There is no reason at all to make new flashy stuff then butcher them down to the craptastic MD3's.
Quote from: jm82792 on January 10, 2011, 12:35:46 AMdemand to create new entities for the new engine.
Depends. for example xreal (afaik) support md3 and all quake stuff. So current stuff can be used with possibility of improvement. But anyway talks about it right now just waste of time. For me personally all clear, im not waiting for engine improvements anymore. All im waitng right now is final 1.2 release, so me and our clan devs can make 1.1-like mod with some improvements.
Quote from: CATAHA on January 10, 2011, 01:00:12 AM
Quote from: jm82792 on January 10, 2011, 12:35:46 AMAll im waitng right now is final 1.2 release, so me and our clan devs can make 1.1-like mod with some improvements.
If you've got a clan with developers sitting around twiddling their thumbs why not get them working on an xreal port, or maybe even some of the bits and pieces that need to be sorted for 1.2(any good at sourcing audio?), since you're waiting for its release before you fiddle?
Yeah that's how I see it.
Same stuff new engine then slowly upgrade it.
Quote from: jm82792 on January 10, 2011, 12:59:32 AM
If there was a NEW engine that supported MD5's or something that good then I'd be making some of them.
There is no reason at all to make new flashy stuff then butcher them down to the craptastic MD3's.
Would IQM (http://lee.fov120.com/iqm/) be good enough for your purposes ?
Quote from: Tremulant on January 10, 2011, 02:18:35 AM
If you've got a clan with developers sitting around twiddling their thumbs why not get them working on an xreal port, or maybe even some of the bits and pieces that need to be sorted for 1.2(any good at sourcing audio?), since you're waiting for its release before you fiddle?
First at all.. devs obviously proved that they dont need some additional source code from community. And about XReal port. It demands client changing. Real and serious client changing. So its like creating new branch of a game, but while tremfusion users still can use official servers, xreal users cant (due to big difference between maps). Why should we waste time on things renounced by developers, and will not be used by community? All we can is make mod which changing server-side code and assets.
PS Also we too love Tremulous to just steal current assets/code and make 'XReal version' of the game. Trem community weak enough already to split it more. =\
Quote from: CATAHA on January 10, 2011, 10:41:42 AM
PS Also we too love Tremulous to just steal current assets/code and make 'XReal version' of the game. Trem community weak enough already to split it more. =\
You're not going to split the trem community with a hastily bodged together port to xreal, it'll be a curiosity at best, but if you can't be arsed you can't be arsed, no problem.
Will you still use the 'official' version of the game, if there will be the same game, but on the XReal engine? The full transfer of data, similar gameplay, but with an improved engine and features. Personally, I would pass on an updated version of the game like many of my friends. That's what I mean when I talk about the split of community.
Quote from: CATAHA on January 10, 2011, 06:08:41 PM
Will you still use the 'official' version of the game, if there will be the same game, but on the XReal engine? The full transfer of data, similar gameplay, but with an improved engine and features. Personally, I would pass on an updated version of the game like many of my friends. That's what I mean when I talk about the split of community.
Of course people would play a Tremulous with a better engine. You seem to assume though that the change will happen overnight. The playerbase won't really split since it'll take years to develop.
Only when it actually gets to the point where it's actually an improvement over the main distribution, which is going to require some considerable effort beyond just porting, if you get to that stage then you deserve to draw that attention and your work is valuable, the devs should want to work with your artists to improve the official trem release.
If all you end up with is an incompatible port of trem to xreal with some really ugly and overused bumpmapping and only partial support for existing maps then you'll have trouble splitting anyone but the most easily impressed of idiots away from trem proper.
Stop making excuses.
Quote from: Meisseli on January 10, 2011, 06:49:07 PM
Of course people would play a Tremulous with a better engine. You seem to assume though that the change will happen overnight. The playerbase won't really split since it'll take years to develop.
Not years if it just question of rendering engine upgrade. Especially considering that XReal is compatible with q3 and only few assets should be redone. =)
Quote from: Tremulant on January 10, 2011, 06:50:41 PM
Only when it actually gets to the point where it's actually an improvement over the main distribution, which is going to require some considerable effort beyond just porting, if you get to that stage then you deserve to draw that attention and your work is valuable, the devs should want to work with your artists to improve the official trem release.
The existence of the Tremfusion project refutes this. We have tested and fully working improved code, but no one care implement those features to main Tremulous branch. Why you think something gonna change after releasing of full XReal port?
Quote from: CATAHA on January 10, 2011, 07:18:48 PM
Quote from: Meisseli on January 10, 2011, 06:49:07 PM
Of course people would play a Tremulous with a better engine. You seem to assume though that the change will happen overnight. The playerbase won't really split since it'll take years to develop.
Not years if it just question of rendering engine upgrade. Especially considering that XReal is compatible with q3 and only few assets should be redone. =)
If it's just a rendering engine upgrade you want, why even bother to upgrade? If you get nothing new and cool out of it?
Quote from: CATAHA on January 10, 2011, 07:18:48 PM
Quote from: Tremulant on January 10, 2011, 06:50:41 PM
Only when it actually gets to the point where it's actually an improvement over the main distribution, which is going to require some considerable effort beyond just porting, if you get to that stage then you deserve to draw that attention and your work is valuable, the devs should want to work with your artists to improve the official trem release.
The existence of the Tremfusion project refutes this. We have tested and fully working improved code, but no one care implement those features to main Tremulous branch. Why you think something gonna change after releasing of full XReal port?
Hah, stop talking trash. Tremfusion had a huge amount of unnecessary and messy features, but it also introduced some nice things. You really don't seem to have noticed that a lot of those good features are already included in the next release. The project has also been dead for almost 1,5 years.
So tremfusion and a complete and graphically superior port to xreal are similar wrt level of effort required? Tremfusion died without ever going anywhere, didn't it? Wasn't the plan for it to be more than just an enhanced 1.1 client?
Talking up your developers abilities while using the long wait for 1.2 as an excuse for them to never make use of said abilities, nice, carry on.
Imagine, if you were working on a port you could get some practice in mapping with all those new features you so desperately want,
I bet you can't make trem look as pro as UrTHD though
(http://i.imgur.com/ChIoA.jpg)
Quote from: Tremulant on January 10, 2011, 07:48:03 PM
Tremfusion died without ever going anywhere, didn't it? Wasn't the plan for it to be more than just an enhanced 1.1 client?
Talking up your developers abilities while using the long wait for 1.2 as an excuse for them to never make use of said abilities, nice, carry on.
Imagine, if you were working on a port you could get some practice in mapping with all those new features you so desperately want,
I bet you can't make trem look as pro as UrTHD though
/...screenshot excluded.../
I cant make trem look like urthd for sure, obviously urt engine better, so when i'm working under trem engine i'm limited.
AFAIK Tremulous 1.2 code differs from the 1.1, so right now working on 1.1 is waste of time. If you dont get it i dont see point explain more. We released InstaGib mod under 1.1 Trem already with bonuses, different footsteps, new possibilities, etc. So saying we not doing anything is lolly. However, after the announcement that Trem 1.2 coming soon, we have suspended work to avoid wasting time for nothing.
And if you asking about my personal work, then you can check my last dev screenshots for example: http://tremulous.net/forum/index.php?topic=3628.msg215336#msg215336 (http://tremulous.net/forum/index.php?topic=3628.msg215336#msg215336)
I personally think as map my better than on your screenshot (uptown i think), more detailed, etc:
(http://www.tremlair.krond.ru/images/c/1/4d2b6cb1726c14d2b6cb1726f9.jpg)
But i can compile my map under new urt engine and it will be much more impressive.
Quote from: Meisseli on January 10, 2011, 07:33:53 PM
If it's just a rendering engine upgrade you want, why even bother to upgrade? If you get nothing new and cool out of it?
Its only answer to ideas 'we dont need to switch engine caus after it we strongly need redone all assets'. even with basic tremfusion improvements standart trem maps look like a lot better. And you always can release some sort of 'new assets' pack with improved models, sounds, maps, etc.
Quote from: Meisseli on January 10, 2011, 07:33:53 PM
Hah, stop talking trash. Tremfusion had a huge amount of unnecessary and messy features, but it also introduced some nice things. You really don't seem to have noticed that a lot of those good features are already included in the next release. The project has also been dead for almost 1,5 years.
Never heard about some real features from tremfusion was implemented to 1.2
Can you give me examples? No offence, im rly curious. I agree that tremfusion not ideal, but some features really good.
PS Crap, sorry guys... My English is too weak to accurately describe my ideas. =(
To be honest, I've given up on an "HD" Tremulous (we've apparently decided "HD" means "better models, more detailed textures, and an engine less than a decade old", so I'll go with that). There's too much infighting, too many conflicting goals, and not enough manpower to make Tremulous any more impressive to potential new players than it is. But finally getting 1.2 out, after more than 4 years, seems like an admirable goal for now.
Quote from: CATAHA on January 10, 2011, 08:37:52 PM
If you dont get it i dont see point explain more.
If it'll mean less crap being spouted, i welcome this decision.
Quote from: CATAHA on January 10, 2011, 08:37:52 PM
We released InstaGib mod under 1.1 Trem already with bonuses, different footsteps, new possibilities, etc. So saying we not doing anything is lolly.
ZOMG KILLAR FITURE!!!1! I haven't seen you produce anything vaguely interesting in the way of mods, i'm not for a moment disputing you mapping abilities.
Quote from: CATAHA on January 10, 2011, 08:37:52 PM
I personally think as map my better than on your screenshot (uptown i think), more detailed, etc:
The screenshot i posted was shit, every aspect of it, not just the map. But it's called HD, so it's awesome, right?
Quote from: CATAHA on January 10, 2011, 08:37:52 PM
PS Crap, sorry guys... My English is too weak to accurately describe my ideas. =(
I'm not sure that explains everything, sadly.
I never said that just HD engine is awesome without any assets, etc. I only said that with improved engine Trem community gonna have possibilities bring game to new level of quality.
About mods... You never played our Instagib mod, right? =) And what about footsteps, heh? When you get different footstep sound when walking on grass it making game more atmospheric. Its just small detail. But such details making games good. Without attention to details games just plain.
PS Again about ur screenie. model looks better than in Trem, even with fact its from urt alpha and gonna be replaced. =]
I played an instagib mod of some description a few years back, it involved humans shooting humans with MDs, it took place on a map that reminds me of the one in your sig, it wasn't much fun.
What would you do if you got the engine improvements you want? would you start working on all the replacement assets to make it worth while or would you just start adding bumpmapping to maps? What can you, ignoring your team of clan-devs, actually do once those renderer enhancements appear?
Years? Seems it was Spanish instagib version. Our was made not so long time ago and it more improved than just 'tk+knockback' version.
Im not great modeller (last time worked in 3dsmax years ago), so cant give much help with model animation. But i can work on re-texturing and maps remaking. If your question is 'with new engine can you remake Tremulous alone' then answer is NO. But after all i'm not alone here, a lot of creative peoples working on Trem. Do you think they going refuse new possibilities? I wish Trem long life, thats why i care about game improvement and upgrade. Tremulous amazing game with incredible gameplay, but it need some more for attracting players nowdays. Tremulous really deserves better than oblivion after all these years.
Quote from: CATAHA on January 10, 2011, 10:47:00 PM
Tremulous really deserves better than oblivion after all these years.
This
yeah, it does. They have to release 1.2 before commercialing the game. Trem would be very good on the markets. Its Action, Strategy and no other game is like it. I was thinking steam but it needs to stay open source.
Quote from: CATAHA on January 10, 2011, 10:47:00 PM
Tremulous really deserves better than oblivion after all these years.
Don't get your hopes up.
Quote from: Pazuzu on January 10, 2011, 08:54:49 PM
To be honest, I've given up on an "HD" Tremulous (we've apparently decided "HD" means "better models, more detailed textures, and an engine less than a decade old", so I'll go with that). There's too much infighting, too many conflicting goals, and not enough manpower to make Tremulous any more impressive to potential new players than it is. But finally getting 1.2 out, after more than 4 years, seems like an admirable goal for now.
Quote from: swamp-cecil on January 10, 2011, 11:25:55 PMIts Action, Strategy and no other game is like it. I was thinking steam but it needs to stay open source.
There also Natural Selection 2. But i still think Tremulous is better. =D
Quote from: CATAHA on January 10, 2011, 10:47:00 PM
Years? Seems it was Spanish instagib version. Our was made not so long time ago and it more improved than just 'tk+knockback' version.
Taking a closer look at your map, the one i remember is pretty crude by comparison, is there a thread somewhere for your instagib?
Quote from: CATAHA on January 10, 2011, 10:47:00 PM
But after all i'm not alone here, a lot of creative peoples working on Trem. Do you think they going refuse new possibilities?
New possibilities are lovely, but they're not necessary to improve upon the existing game, we haven't hit the limits of ioq3 yet.
We need an end to all this pointless speculation, if you want the renderer improvements then go code them or make the port, if you don't care that much about them then work on improving assets up to the limits of the existing engine.
Assets already reached limit. =) MAy be im wrong, but can you give me example then? afaik all possibilities of ioQ3 was used in mods and maps.
About instagib, it wasnt anounced on forums. We worked on 'final' release of mod, but 1.2 release was anounced, so right now mod development suspended due to difference between 1.2 and 1.1 code. I can describe mod, may it that you played. Mainly we have basic instagib with instakill md, system of random bonuses (different weapons, bulk of nades, invisibility, plague, etc) on killstreak, becoming lisk after 'out of ammo', 'butcher' feature (instead of lisk random evolving to tyrant), invisible nodes, special 'highlander esd mode on end, 'arcade' moving style (jumps from walls, improved circlejumping code, crouch-sliding, etc). Thats simplified description of mod.
Quote from: CATAHA on January 10, 2011, 11:35:35 PM
Quote from: swamp-cecil on January 10, 2011, 11:25:55 PMIts Action, Strategy and no other game is like it. I was thinking steam but it needs to stay open source.
There also Natural Selection 2. But i still think Tremulous is better. =D
You just had to make me look that up, didn't you? Now I can't wait for it to come out. :o
Not at all, just noticed.
Quote from: CATAHA on January 11, 2011, 12:52:17 AM
Assets already reached limit. =) MAy be im wrong, but can you give me example then?
There are only a few alien, human, and buildable models/animations that look that good. The rest could be improved significantly. I very much think the community could make a competition or something to improve most of the models currently in the game (of course keeping in mind the upcoming chompers). Also, why not make a big graphical update on every default map for example, or work to make the sounds that need to be replaced? We've hardly reached a limit in anything in my opinion.
I don't really get the we-need-an-engine-transition-i'm-not-creating-any-new-assets philosophy. That's just people being lazy. Make a great upgrade of an alien model for example, and I guarantee that it will be praised and included in the next version.
I bet the devs could just add a strong environment mapping effect(or whatever the hell that shiny stuff you see on the tesla and a couple of other structures is, i have no idea what i'm talking about, sorry) to absolutely everything in the game and convince at least half the players that they've just made a huge improvement to the engine. I'm only partly joking, it does seem to be an underused effect that looks rather nice in the right setting, on nano for instance.
Quote from: Meisseli on January 12, 2011, 03:25:27 PM
There are only a few alien, human, and buildable models/animations that look that good. The rest could be improved significantly. I very much think the community could make a competition or something to improve most of the models currently in the game (of course keeping in mind the upcoming chompers). Also, why not make a big graphical update on every default map for example, or work to make the sounds that need to be replaced? We've hardly reached a limit in anything in my opinion.
I don't really get the we-need-an-engine-transition-i'm-not-creating-any-new-assets philosophy. That's just people being lazy. Make a great upgrade of an alien model for example, and I guarantee that it will be praised and included in the next version.
New models and textures? Its not question of engine limits. I can make highly-detailed map and it gonna lag like hell... Or you improve human model and apply to it more detailed textures. Right now many players crying due to heavy ATCS lags on bases. No imagine what lags they gonna have with more-poly models and high-res textures. Q3 engine just not optimal enough for endless improvement and not supporting modern hardware acceleration. So thats limit. Using 1024x1024 textures with Q3 rendering procedures wont make much visual difference, only result will be much lags/fps drop. =\
Quote from: CATAHA on January 12, 2011, 07:33:26 PM
Using 1024x1024 textures with Q3 rendering procedures wont make much visual difference, only result will be much lags/fps drop. =\
Using larger textures would *not* matter for 90% of the surfaces as they don't use the highest mip map level of the texture anyway. But you are right that the Q3 engine doesn't exploit the capability of modern GPUs.
Quote from: CATAHA on January 12, 2011, 07:33:26 PM
Using 1024x1024 textures with Q3 rendering procedures wont make much visual difference, only result will be much lags/fps drop. =\
Really? Many trem textures are extremely low res and some appear to have been wrecked by jpeg compression, do you really think we're at the upper limit there? You've talked about rebrushing existing textures in the past, do you feel it's not worth bothering now?
Quote from: CATAHA on January 12, 2011, 07:33:26 PM
Quote from: Meisseli on January 12, 2011, 03:25:27 PM
There are only a few alien, human, and buildable models/animations that look that good. The rest could be improved significantly. I very much think the community could make a competition or something to improve most of the models currently in the game (of course keeping in mind the upcoming chompers). Also, why not make a big graphical update on every default map for example, or work to make the sounds that need to be replaced? We've hardly reached a limit in anything in my opinion.
I don't really get the we-need-an-engine-transition-i'm-not-creating-any-new-assets philosophy. That's just people being lazy. Make a great upgrade of an alien model for example, and I guarantee that it will be praised and included in the next version.
New models and textures? Its not question of engine limits. I can make highly-detailed map and it gonna lag like hell... Or you improve human model and apply to it more detailed textures. Right now many players crying due to heavy ATCS lags on bases. No imagine what lags they gonna have with more-poly models and high-res textures. Q3 engine just not optimal enough for endless improvement and not supporting modern hardware acceleration. So thats limit. Using 1024x1024 textures with Q3 rendering procedures wont make much visual difference, only result will be much lags/fps drop. =\
So you think the current stuff is at its max? Your honest opinion is that for example the human model is the best-looking, state-of-the-art quality one is able to make with Q3 without getting heavy performance problems?
Its like driving car at max possible speed. You overheating engine, breaking car. Best engine is the one that has a reserve of power. Yes, we can improve all those things. But look... exchanging all jpeg textures will enlarge installer size. For example map with jpeg textures have 5mb size, but when i switch to tga sources it become over 20mb size. Real ingame effect (due to Q3 limitations) quite small. Sure we can do all that stuff and it will improve picture. But it's not worth it.
PS Lil example. One guy show me his new lasgun model (not so low-poly). That modal had 200 triangles more than old one. You can say its few, but... x10 humans at base with lasguns = 2000 triangles.
According ioQ3 specification:
Quoteioquake3 forces everything through the CPU and you hit performance limits with scenes involving 60,000 triangles on hardware that can easily do scenes of 1,000,000 to 10,000,000 triangles
.
So with every small improvement we closer and closer to engine 'red zone'. Most modern engines in addition to improved productivity as well use the effects to make the surface depth without increasing the number of triangles. Generalizing all the above - we can not seriously improve situation using the current engine.
+1
Quote from: CATAHA on January 12, 2011, 11:06:52 PM
Its like driving car at max possible speed. You overheating engine, breaking car. Best engine is the one that has a reserve of power. Yes, we can improve all those things. But look... exchanging all jpeg textures will enlarge installer size. For example map with jpeg textures have 5mb size, but when i switch to tga sources it become over 20mb size. Real ingame effect (due to Q3 limitations) quite small. Sure we can do all that stuff and it will improve picture. But it's not worth it.
PS Lil example. One guy show me his new lasgun model (not so low-poly). That modal had 200 triangles more than old one. You can say its few, but... x10 humans at base with lasguns = 2000 triangles.
According ioQ3 specification:
Quoteioquake3 forces everything through the CPU and you hit performance limits with scenes involving 60,000 triangles on hardware that can easily do scenes of 1,000,000 to 10,000,000 triangles
.
So with every small improvement we closer and closer to engine 'red zone'. Most modern engines in addition to improved productivity as well use the effects to make the surface depth without increasing the number of triangles. Generalizing all the above - we can not seriously improve situation using the current engine.
Quote from: CATAHA on January 12, 2011, 11:06:52 PM
But look... exchanging all jpeg textures will enlarge installer size. For example map with jpeg textures have 5mb size, but when i switch to tga sources it become over 20mb size.
Are you serious? Don't use TGA for textures unless you need the alpha channel, JPEG is fine, but the existing textures can be redone at a slightly higher resolution and saved with a higher quality setting. Even if they're not scaled up, the textures are hardly state of the art, i feel there's some room for improvement even within the limits of existing resolutions.
This is a silly example using an unfeasibly large texture, but look, it's more detailed than the old one, shock horror.
(http://i.imgur.com/DDQ3j.jpg) (http://i.imgur.com/DDQ3j.jpg)
Quote from: CATAHA on January 12, 2011, 11:06:52 PM
Real ingame effect (due to Q3 limitations) quite small. Sure we can do all that stuff and it will improve picture. But it's not worth it.
Not worth it why? Again, we're working around limitations of an old engine here, but do stannum's new weapon models and skins look no better than the existing ones? They seem pretty bloody good to me, as a layman.
You're a big fan of UrT, it obviously uses higher poly models than trem but on the same engine, do you feel that it's unacceptably laggy because of this?
Quote from: CATAHA on January 12, 2011, 11:06:52 PM
we can not seriously improve situation using the current engine.
You're right, but then we can't improve the situation with any engine, as we're all a bunch of lazy defeatists.
Quote from: Tremulant on January 13, 2011, 05:35:06 AM
You're a big fan of UrT, it obviously uses higher poly models than trem but on the same engine, do you feel that it's unacceptably laggy because of this?
Im big fan of Trem, not UrT. And about engine - urt dev improving it with every release to get better speed and quality, so you already cant say they 'just using ioQ3'
Quote from: CATAHA on January 13, 2011, 01:30:46 PM
Im big fan of Trem, not UrT. And about engine - urt dev improving it with every release to get better speed and quality, so you already cant say they 'just using ioQ3'
Every release? They've had two releases, one of which was the initial standalone, right? What kind of engine improvements went into 4.1?
Quote from: CATAHA on January 10, 2011, 09:12:24 PM
I never said that just HD engine is awesome without any assets, etc. I only said that with improved engine Trem community gonna have possibilities bring game to new level of quality.
About mods... You never played our Instagib mod, right? =) And what about footsteps, heh? When you get different footstep sound when walking on grass it making game more atmospheric. Its just small detail. But such details making games good. Without attention to details games just plain.
PS Again about ur screenie. model looks better than in Trem, even with fact its from urt alpha and gonna be replaced. =]
I like those footsteps. You did a great job adding them. I don't like Instagib, but I love your maps anyway.
I'm not waiting for 1.2 because it's been a wait too long for something that apparently is not as "great" it has been promoted to be. I've read the "soon coming, soon coming, on it's way" for so long, that it's like reading the excuses for the delays in a government project. I have not been impressed by the 1.2beta either. I will be sticking with 1.1 and it's wonderful variety of mods for awhile yet. Waiting for someone else to do things, as many people on Tremulous seem to do, means just waiting for it not to get done.
The Unvanquished (http://unvanquished.net/forum/) is hosting a new community-driven project called TremHD (http://tremhd.unvanquished.net/forum/), which aims to make assets for Tremulous clients that utilize bump mapping features, as well as implement better support for wide-screen displays.
The TremHD forums will serve as a roadmap for development, as well as a place to discuss and learn the techniques needed to make the new assets.
The project has not officially 'launched' yet, but I would love to get some feedback on the site, and get some additional help setting things up if anyone has time! :D
Quote from: cron on January 30, 2011, 04:09:09 AM
The Unvanquished (http://unvanquished.net/forum/) is hosting a new community-driven project called TremHD (http://tremhd.unvanquished.net/forum/), which aims to make assets for Tremulous clients that utilize bump mapping features, as well as implement better support for wide-screen displays.
The TremHD forums will serve as a roadmap for development, as well as a place to discuss and learn the techniques needed to make the new assets.
The project has not officially 'launched' yet, but I would love to get some feedback on the site, and get some additional help setting things up if anyone has time! :D
Where's the IRC channel you keep mentioning?
Quote from: Pazuzu on January 30, 2011, 04:49:06 AM
Quote from: cron on January 30, 2011, 04:09:09 AM
The Unvanquished (http://unvanquished.net/forum/) is hosting a new community-driven project called TremHD (http://tremhd.unvanquished.net/forum/), which aims to make assets for Tremulous clients that utilize bump mapping features, as well as implement better support for wide-screen displays.
The TremHD forums will serve as a roadmap for development, as well as a place to discuss and learn the techniques needed to make the new assets.
The project has not officially 'launched' yet, but I would love to get some feedback on the site, and get some additional help setting things up if anyone has time! :D
Where's the IRC channel you keep mentioning?
He didn't...
Barf, jpegs.
Isn't it finally time to abandon those lossy formats when space and bandwidth isn't an issue anymore?
Most games use the .DDS (http://en.wikipedia.org/wiki/DirectDraw_Surface) format for textures, they can be decompressed on the fly by the GPU.
Quote from: CreatureofHell on January 30, 2011, 12:13:16 PM
Quote from: Pazuzu on January 30, 2011, 04:49:06 AM
Quote from: cron on January 30, 2011, 04:09:09 AM
The Unvanquished (http://unvanquished.net/forum/) is hosting a new community-driven project called TremHD (http://tremhd.unvanquished.net/forum/), which aims to make assets for Tremulous clients that utilize bump mapping features, as well as implement better support for wide-screen displays.
The TremHD forums will serve as a roadmap for development, as well as a place to discuss and learn the techniques needed to make the new assets.
The project has not officially 'launched' yet, but I would love to get some feedback on the site, and get some additional help setting things up if anyone has time! :D
Where's the IRC channel you keep mentioning?
He didn't...
On the site.
You can access our chat room #unvanquished on the Freenode IRC network by clicking the 'Chat' button on the Unvanquished forums.
Quote from: Cadynum on January 30, 2011, 02:31:45 PM
Barf, jpegs.
Isn't it finally time to abandon those lossy formats when space and bandwidth isn't an issue anymore?
Tremulous installer gonna be 2Gb size then =D
P2P will fix all your woes.
Quote from: gimhael on January 30, 2011, 03:15:19 PM
Most games use the .DDS (http://en.wikipedia.org/wiki/DirectDraw_Surface) format for textures, they can be decompressed on the fly by the GPU.
The compression is patented though...
Quote from: jm82792 on January 31, 2011, 03:45:45 AM
P2P will fix all your woes.
Nope. I dont need brick size cellular phone if other phone models can provide same functions with smaller size. Not question of 'how hard to download it'. =)
Quote from: Odin on January 31, 2011, 11:20:19 AM
Quote from: gimhael on January 30, 2011, 03:15:19 PM
Most games use the .DDS (http://en.wikipedia.org/wiki/DirectDraw_Surface) format for textures, they can be decompressed on the fly by the GPU.
The compression is patented though...
Yes, but the game engine does not need to decompress the data, and there are free tools (http://code.google.com/p/nvidia-texture-tools/) available for compression which have licensed (http://code.google.com/p/nvidia-texture-tools/wiki/FAQ#Can_I_use_the_NVIDIA_Texture_Tools_in_the_US?_Do_I_have_to_obtai) the S3 patent.
Quote from: CATAHA on January 31, 2011, 02:34:02 AM
Tremulous installer gonna be 2Gb size then =D
The stock maps are about 50MB now, i highly doubt they would increase in size by a multiple of 40.
Even if they were 2GB is not a problem.
Even if we took the brute-force approach and stored everything with some batshit-insanely high-quality format like Targa, keep in mind everything gets compressed in the pk3 files, and textures don't take up the whole archive as it is.
Quote from: Cadynum on January 31, 2011, 04:18:36 PM
The stock maps are about 50MB now, i highly doubt they would increase in size by a multiple of 40.
Even if they were 2GB is not a problem.
When user downloading game of such size he expect something more than pack of high-res art.
Quote from: Pazuzu on January 31, 2011, 04:35:55 PM
Even if we took the brute-force approach and stored everything with some batshit-insanely high-quality format like Targa, keep in mind everything gets compressed in the pk3 files, and textures don't take up the whole archive as it is.
Live example: Map with jpegs 4mb. Same map with original tgas 29mb. Not so huge visual difference. When i conecting to slow server i should wait x7 more time to download map. =D
Quote from: CATAHA on January 31, 2011, 05:55:49 PMQuote from: Pazuzu on January 31, 2011, 04:35:55 PM
Even if we took the brute-force approach and stored everything with some batshit-insanely high-quality format like Targa, keep in mind everything gets compressed in the pk3 files, and textures don't take up the whole archive as it is.
Live example: Map with jpegs 4mb. Same map with original tgas 29mb. Not so huge visual difference. When i conecting to slow server i should wait x7 more time to download map. =D
Ahem.
Quote from: Pazuzu on January 31, 2011, 04:35:55 PM
everything gets compressed in the pk3 files
Compressed jpegs = 4mb, compressed tgas = 29mb. Sure i noticed those values compressed in pk3. Or you saw maps in other kinds?
What resolution are you using?
Its just example, lol. Resolutions vary from texture, but commonly it from 128x256 to 512x512.
PNG?
Have you actually looked through the asset files? Textures are nothing compared to model files.
The tyrant model for example is 1,846 KB compared to it's texture which is just 77 KB.
It seems like on one hand you're complaining about the slight increase in texture size required for a big visual difference, and on the other hand you want XReal and all the fancy graphics that would add MUCH more to the size. Nevermind that you then have to also recreate all the assets anyway...
Quote from: Nux on February 01, 2011, 04:21:47 PM
Have you actually looked through the asset files? Textures are nothing compared to model files.
The tyrant model for example is 1,846 KB compared to it's texture which is just 77 KB.
It seems like on one hand you're complaining about the slight increase in texture size required for a big visual difference, and on the other hand you want XReal and all the fancy graphics that would add MUCH more to the size. Nevermind that you then have to also recreate all the assets anyway...
Erm, yep, welcome to discussions involving CATAHA, fun eh?
Quote from: Nux on February 01, 2011, 04:21:47 PM
Have you actually looked through the asset files? Textures are nothing compared to model files.
Zipped tyrant is 1.2 MB. Anyway, go compare amount of textures and amount of models. Also tyrant seems be one of the "heaviest" models. I guess all models put together wouldn't take more than 15-20MB (simple guess, as weapons md3's take less than 50KB each), while texture set for arachnid is 8MB.
PNG's don't seem to be that lighter than TGA's (400KB first, 460KB second in zips) still being twice as large as JPG file.
Sure, the installer size is not that much of an issue, yet is it worth the effort? I think most people wouldn't really notice the difference between jpgs and tgas without good comparison and still the fact is that 700MB looks a bit better than 1.2GB.
At the very least, we could save the JPGs with a higher quality setting. The increased file size might even get trimmed down a bit more with the pk3 compression.
Quote from: Pazuzu on February 01, 2011, 06:42:48 PM
At the very least, we could save the JPGs with a higher quality setting. The increased file size might even get trimmed down a bit more with the pk3 compression.
Only barely, if at all, some images may even grow but i suppose all those headers will give you a saving in bulk, anyway, JPEG compression works so well for most textures that the savings are big enough even when jpeg'd at quite high quality settings.
As asvarox mentions, the difference between TGA and PNG for our purposes is only really at what stage the compression is applied, it being practically the same compression method and raw data, yes zipping a TGA is somewhat less efficient but for the kind of resolutions we're talking about the size differences wont be huge.
JPEG artifacts, as with any other image quality deficiencies, will become more visible when the image is stretched across a model, but are they so noticeable that they'll be a problem if the texture's higher res to begin with, only jpeg'd the once and at a decent quality setting?
Where's this discussion going, anyway?
Quote from: Tremulant on February 01, 2011, 07:08:33 PM
Where's this discussion going, anyway?
I don't know, but this is where it should be going:
Quote from: cron on January 30, 2011, 04:09:09 AM
The Unvanquished (http://unvanquished.net/forum/) is hosting a new community-driven project called TremHD (http://tremhd.unvanquished.net/forum/), which aims to make assets for Tremulous clients that utilize bump mapping features, as well as implement better support for wide-screen displays.
The TremHD forums will serve as a roadmap for development, as well as a place to discuss and learn the techniques needed to make the new assets.
The project has not officially 'launched' yet, but I would love to get some feedback on the site, and get some additional help setting things up if anyone has time! :D
Quote from: Asvarox on February 01, 2011, 06:32:29 PM
Quote from: Nux on February 01, 2011, 04:21:47 PM
Have you actually looked through the asset files? Textures are nothing compared to model files.
Zipped tyrant is 1.2 MB. Anyway, go compare amount of textures and amount of models. Also tyrant seems be one of the "heaviest" models. I guess all models put together wouldn't take more than 15-20MB (simple guess, as weapons md3's take less than 50KB each), while texture set for arachnid is 8MB.
If you're complaining that I've used a heavy model as an example, then I find that funny. You acknowledge that the tyrant is indeed a case where we can improve the texture assets with little cost to file size? Well then it wouldn't matter if there were loads of textures compared to models, we've found a case that can be improved upon. I pressume you thought improving a game meant trying to fix the parts that don't need fixing.
The zipped model is indeed less than the non-zipped file. This isn't news to me. The bigger file compresses better than the smaller file. This still isn't news to me. The comparative size between the two files in both states is the same to about 0.01 difference in the ratios.
Also, you need to factor in the degree of visual improvement. For example, the basi has a tiny texture size (even when summing the sizes of the base and adv version) compared to it's model size which is more than the tyrant's. Yet the texture looks good and I would go as far as to say it's the best looking alien by far.
As for maps, I looked at ATCS for example and all it's textures combined where a quarter of the size of the .bsp file. If you find a map where the textures add up to more, chances are they've gone WAY over the top with pictures.
I want to introduce everyone to a project I've been working on, and would like to get your advice on some things...
(http://tremhd.unvanquished.net/logo_huge.png) (http://tremhd.unvanquished.net/forum/)
http://tremhd.unvanquished.net/forum/
TremHD is an open-assets based project to make new assets for Tremulous using high resolution textures
with bump mapping, aiming to make Tremulous look better graphically (overall and also particularly on widescreen monitors). These assets could then be freely used by
any Tremulous client.
TremHD will focus heavily on educating the average Tremulous player / new modder on some of the finer points of graphical asset creation using open source tools (primarily Blender and GIMP).
Quote from: gimhael on November 29, 2010, 10:06:58 AM
Quote from: Odin on November 29, 2010, 06:50:27 AM
Every few months there's a thread just like this, which makes me somewhat hoping for an XreaL port of Trem. Every one of these threads ends disappointingly with nothing.
Until someone(with actual knowledge in how this stuff works) does something to make that a reality, you're wasting your time.
Well there have been not only threads but also projects to port Trem over to Xreal, i know of the Tremfusion attempt to include a Xreal-based renderer and the Xtr3m project.
I think the big problem with this kind of project is that they lack a clearly defined goal. Usually they start with 'we want some nicer graphics', but then the want-to-have list is expanded (correct physics, vehicles, scriptable maps, game modes, new weapons/classes, whatever) until the project is so big that it is completely impossible to do with the available people.
With these statements in mind, the goal of TremHD is purely to make new assets for Tremulous that could work nicely with any engine (and not much else), but we do hope to use Gimhael's bump mapping code for testing assets, and will continue to advocate graphical improvements to Tremulous, regardless of client.
I believe that very clear goals and reputable names at the helm to educate can make this a successful community driven project, so I'd like to know if some of the people here would be interested in being project leaders and advisors.
Please check out the site, and feel free to PM me (http://tremulous.net/forum/index.php?action=pm;sa=send;u=7713) to get involved today!
I've created some truly hideous textures (http://imgur.com/a/374Zy) while attempting to produce a replacement for the atcs outside floor, needless to say i didn't succeed but if you can find a use for any do feel free.
Procedural goodness........
Takes lots of time to get good procedurals and lots of layers.
And I'm interested in helping with your cause cron and know how to use Blender :)
Quote from: Nux on February 02, 2011, 10:09:33 AM
Also, you need to factor in the degree of visual improvement. For example, the basi has a tiny texture size (even when summing the sizes of the base and adv version) compared to it's model size which is more than the tyrant's. Yet the texture looks good and I would go as far as to say it's the best looking alien by far.
The size of the basi model is so much bigger than the tyrant because of the large amount of animation frames it has.
I think this was not intentional, and was just a result of the basi being made first, before Overflow had a lot of experience animating (I think).
Also, I think the quality of the texture is just an issue of MoP vs. Stannum's texturing skills.
You make a good point. It would indeed seem that animation is the overriding factor here. So here we have another thing to be aware of when it comes to improving assets and particularly with file size (if it is indeed an issue for you). Would I be right in saying that the use of skeletons would vastly reduce the cost of storing animation info? I would guess so because a much smaller number of points are used to describe the animation and if formats like md5 also interpolate heavily, the size could be brought down further.
You see CATAHA, this is the kind of argument you should be making.
Wouldn't skeletons require armatures, which MD3 doesn't support? IIRC that's why they're stored as vertex animations in the first place.
skeletons = armatures
Yes, md3 doesn't have this. md5 does though and change of model file format that is the sort of change that is being proposed here.
Well, I have implemented an IQM loader for tremulous, (it is a much nicer format than MD5), so you could use skeletal models in Tremulous already. The problem is that if you can't switch all players over to the new model format at the same time you'll have to include *both* in the pk3s.
(Also if you want real skeletal animation, i.e. that the game can animate individual bones, then you'll need a new renderer API and consequently different QVMs too.)
Quote from: gimhael on February 03, 2011, 08:25:34 PM
Well, I have implemented an IQM loader for tremulous, (it is a much nicer format than MD5), so you could use skeletal models in Tremulous already. The problem is that if you can't switch all players over to the new model format at the same time you'll have to include *both* in the pk3s.
Awesome! I was hoping someone would implement it! Blender export scripts for IQM are included in the TADA! package.
MD5 or something would would be sweet.
Got a few models that could be skinned and texture painted eventually.
Quote from: Tremulant on February 01, 2011, 07:08:33 PM
Quote from: Pazuzu on February 01, 2011, 06:42:48 PM
At the very least, we could save the JPGs with a higher quality setting. The increased file size might even get trimmed down a bit more with the pk3 compression.
Only barely, if at all, some images may even grow but i suppose all those headers will give you a saving in bulk, anyway, JPEG compression works so well for most textures that the savings are big enough even when jpeg'd at quite high quality settings.
As asvarox mentions, the difference between TGA and PNG for our purposes is only really at what stage the compression is applied, it being practically the same compression method and raw data, yes zipping a TGA is somewhat less efficient but for the kind of resolutions we're talking about the size differences wont be huge.
JPEG artifacts, as with any other image quality deficiencies, will become more visible when the image is stretched across a model, but are they so noticeable that they'll be a problem if the texture's higher res to begin with, only jpeg'd the once and at a decent quality setting?
Where's this discussion going, anyway?
Yes the ZIP compression for the PK3s basically does nothing to an already compressed file format like JPEG or PNG. TGA supports RLE compression, but is not truly lossless, and I don't believe Q3* supports some of the newer .TGA specifications.
Huge space savings could be achieved by using separate images for specular and alpha channels (possibly as 8-Bit PCX even - see these posts on the OA project forums (http://openarena.ws/board/index.php?topic=2823.msg29031#msg29031) about this).
Ideally, I think a new format(s) should be used, especially when you need to add things like normalmaps images into the mix
As gimhael suggested, .DDS or even something resembling Valve's .VTF (http://developer.valvesoftware.com/wiki/Valve_Texture_Format) would work.
Quote from: cron on February 04, 2011, 04:42:36 AM
TGA supports RLE compression, but is not truly lossless
Oh, how so?
And what does an 8bit pcx achieve that an 8bit png wouldn't? i'm a little surprised to see pcx mentioned at all thesedays.
Specular?
Trem has no specular shading capacity right?
If so that's great.
But....
WE NEED SMOOTH SHADING!
Really everything right now renders solid :(
Quote from: cron on February 04, 2011, 04:42:36 AM
Yes the ZIP compression for the PK3s basically does nothing to an already compressed file format like JPEG or PNG.
This really depends on how well the file was compressed originally which in turn depends on the compression method and the target file. In the case of ZIP we don't have to worry about losing information- if you compress lossily over and over you will eventually end up with nothing -but generally once something has been compressed to something without any pattern left you will most likely
increase the size of the file when you try to compress it again.
Also note that as ever, a trade-off is happening when you compress. You don't get something for nothing. If you encode something a lot, it'll take longer to read and if you don't it'll take up more space in memory. This is where you decide which thing is more of a problem for you.
Quote from: Tremulant on February 04, 2011, 05:22:34 AM
Quote from: cron on February 04, 2011, 04:42:36 AM
TGA supports RLE compression, but is not truly lossless
Oh, how so?
And what does an 8bit pcx achieve that an 8bit png wouldn't? i'm a little surprised to see pcx mentioned at all thesedays.
Since you were too lazy to visit the OA forums, here's a post in it's entirety about this:
Quote from: Udi on December 30, 2009, 02:21:20 PM
Quote from: andrewj on December 30, 2009, 11:02:30 AM
Shaders cannot do that.
I think I found something which _seems_ to accomplish what I was looking for, but I lack the knowledge how shaders really work, so please check if it's a viable solution. Basically what this method is about is that, after a blendFunc GL_DST_COLOR GL_SRC_ALPHA step another blendFunc filter will "mask" the second texture according to the first greyscale alpha texture. I've tried it with two transparent textures, and the results seem to be the same.
First example is the metafloor_wall_14_specular texture (OA doesn't use it yet, but you can find it in q3dm16).
(http://udionline.hu/kepek/openarena/pcx-experiment/screen-specular.jpg)
The separated pcx solution is a little bit darker, according to the heppler reference, it's due to the additional blendFunc. The shader definitions used (left the transparent TGA, right the two PCX):
textures/base_wall/metalfloor_wall_14_specular {
qer_editorimage textures/base_wall/metalfloor_wall_14
{
map $lightmap
rgbgen identity
}
{
map textures/base_wall/metalfloor_wall_14_specular
rgbGen identity
blendFunc GL_DST_COLOR GL_SRC_ALPHA
}
}
|
textures/base_wall/metalfloor_wall_14_specular {
qer_editorimage textures/base_wall/metalfloor_wall_14
{
map $lightmap
rgbgen identity
}
{
map textures/base_wall/metalfloor_wall_14_specular-alpha.jpg
rgbGen identity
blendFunc GL_DST_COLOR GL_SRC_ALPHA
}
{
map textures/base_wall/metalfloor_wall_14_specular-color.pcx
rgbGen identity
blendFunc filter
}
}
|
Filesizes (512x512px):
metalfloor_wall_14_specular.tga: 1.0 MB
metalfloor_wall_14_specular-alpha: 248.7 kB (8bit PCX) or 194.9 kB (grayscale JPG)
metalfloor_wall_14_specular-color: 259.5 kB (8bit PCX)
Sum: 1024 kB vs. 508.2 kB
The another example is the cybergrate2 shader, which you can find on the railgun platform of oa_ctf4ish. It's trickier than the previous, because only the metal grid was transparent, the electricity effect wasn't, but due to the method both had to be made transparent. The result:
(http://udionline.hu/kepek/openarena/pcx-experiment/screen-transparency.jpg)
The PCX solution is a bit ugly on the edges, but don't worry about that. Shaders used (left original, right new):
textures/base_floor/cybergrate2
{
surfaceparm metalsteps
cull none
{
map textures/sfx/portal_sfx_ring_electric.tga
tcmod scroll 1 -1
blendfunc add
}
{
map textures/base_floor/cybergrate2.tga
blendFunc blend
rgbGen identity
}
{
map $lightmap
blendFunc filter
rgbGen identity
}
}
|
textures/base_floor/cybergrate2
{
surfaceparm metalsteps
cull none
{
map textures/sfx/portal_sfx_ring_electric-alpha.pcx
tcmod scroll 1 -1
blendFunc GL_DST_ONE_MINUS_COLOR GL_SRC_ALPHA
}
{
map textures/sfx/portal_sfx_ring_electric-color.pcx
tcmod scroll 1 -1
blendFunc filter
}
{
map textures/base_floor/cybergrate2-alpha-mono.pcx
rgbGen identity
blendFunc GL_DST_ONE_MINUS_COLOR GL_SRC_ALPHA
}
{
map textures/base_floor/cybergrate2-color.pcx
rgbGen identity
blendFunc filter
}
{
map $lightmap
blendFunc filter
rgbGen identity
}
}
|
Filesizes (256x256px):
cybergrate2.tga: 132 kB
cybergrate2-alpha: 5.1 kB (8bit PCX) or 3.6 kB (1bit PCX)
cybergrate2-color: 35.7 kB (8bit PCX)
Sum: 132 kB vs. 40.8 kB
Here's a test package so you can try this at home: http://udionline.hu/fajlok/z_pcx-experiment.pk3 (http://udionline.hu/fajlok/z_pcx-experiment.pk3)
The filesize compression is more than 50% in both cases, but of course the shader steps require more computing. Is it worth to deal with this method?
Seems like a nice attempt, though sadly- as you know -there are key differences between the textures (i.e. the darkening in the former comparison and the light edges in the latter).
But you say yourself about the processing time trade-off. Aren't I justified in saying that file size really isn't as much of an issue as processing time with todays computers?
EDIT:
Quote from: jm82792 on February 04, 2011, 05:32:11 AM
WE NEED SMOOTH SHADING!
Really everything right now renders solid :(
Textures are UV mapped so inherently look solid. I think that's what you're seeing. What little shading effect there is seems to be smooth.
Quote from: cron on February 04, 2011, 04:25:51 PM
Quote from: Tremulant on February 04, 2011, 05:22:34 AM
Quote from: cron on February 04, 2011, 04:42:36 AM
TGA supports RLE compression, but is not truly lossless
Oh, how so?
And what does an 8bit pcx achieve that an 8bit png wouldn't? i'm a little surprised to see pcx mentioned at all thesedays.
Since you were too lazy to visit the OA forums, here's a post in it's entirety about this:
*snip*
I visited the forums and saw just that post, at no point did it explain to me how TGAs are lossy or why you'd use PCX instead of PNG, maybe another poster explained that elsewhere but i assumed your copy-paste would have contained that salient piece of information had it been readily available.
I don't know the first thing about 3d texturing, well aside from what you told me in irc, apologies if i'm missing something obvious here.
I was wrong, targas compressed with RLE compression claim to be loseless. However, I guess undesirable antialiasing can occur in TGAs with a lower color depths (lower than 24-bit?)
Quote from: cron on February 04, 2011, 07:29:13 PM
I was wrong, targas compressed with RLE compression claim to be loseless. However, I guess undesirable antialiasing can occur in TGAs with a lower color depths (lower than 24-bit?)
Undesirable anti-aliasing? do you have a fondness for jaggies? So, back to the question, what's this guy's love of PCX all about? Is PCX treated in some special way by ioq3? Is there a good reason that the guy's storing 151 shades of grey as an indexed PCX rather than a greyscale PNG(of course i'm just assuming ioq3 supports PNGs here, i don't know)?
At least hurry up and post the explanation that i was too lazy to read.
The separated PCX method results in additional shader stages which can cause lower performance. Normally it wouldn't be an issue but these are typical shaders that don't necessarily need to be complex.
Anything after two stages requires a second draw pass.
Remember that ioquake3 decompresses all textures and either uploads them to the GPU either in uncompressed RGBA8 form or it recompresses them in DXT1 format. So your graphics card memory limits the overall size of the textures, no matter how you compress them in the pk3.
@tremulant: I guess cron meant to say Colour banding (http://en.wikipedia.org/wiki/Colour_banding).
Quote from: gimhael on February 05, 2011, 07:21:54 AM
@tremulant: I guess cron meant to say Colour banding (http://en.wikipedia.org/wiki/Colour_banding).
Yes, i assumed that was probably what he was getting at.
There still seems to an awful lot of confused excitement around here, vs actual clue about what makes sense.
http://tremhd.unvanquished.net/forum/index.php?topic=18.0 (http://tremhd.unvanquished.net/forum/index.php?topic=18.0)
Got any suggestions for Friend Basi 2.0? :basilisk:
UPDATE: Working on model sheets for the Pazilisk, photos when I'm done.
Rough pencil sketch, uncolored:
(http://thumbnails41.imagebam.com/11846/1df1c4118452837.jpg) (http://www.imagebam.com/image/1df1c4118452837)
Quote from: Pazuzu on February 06, 2011, 05:19:12 PM
http://tremhd.unvanquished.net/forum/index.php?topic=18.0 (http://tremhd.unvanquished.net/forum/index.php?topic=18.0)
Got any suggestions for Friend Basi 2.0? :basilisk:
UPDATE: Working on model sheets for the Pazilisk, photos when I'm done.
Rough pencil sketch, uncolored:
(http://thumbnails41.imagebam.com/11846/1df1c4118452837.jpg) (http://www.imagebam.com/image/1df1c4118452837)
Use a better image host. imgur/photobucket/tinypic/anything besides the site you just used. Also, that's not how the img tag works.
It's how thumbnails work, though. Should I just post the whole thing instead of thumbnailing it?
Nevermind, I misread.
Regardless, thumbnail/full image isn't working for me.
Thumbnail now links to the same image, rehosted on my Dropbox:
(http://thumbnails41.imagebam.com/11846/1df1c4118452837.jpg) (http://dl.dropbox.com/u/16081358/basi-roughsketch.png)
UPDATE: Here's a slightly more detailed version. This time it's thumbnailed with the img tag, and hosted completely on Dropbox:
(http://dl.dropbox.com/u/16081358/basi-pencil-shaded.png) (http://dl.dropbox.com/u/16081358/basi-pencil-shaded.png)
So after this 3D view gets finalized, I'll do front, side (with and without legs), and maybe top sketches based on it, then import all that into Blender and start modeling.
For everything else, the IMG tag can be used like:
[img width=640]http://some.png[/img]
For what it's worth, I think it should appear that the basi's legs/claws could stab through human legs and feet to grab them (in addition to grabbing them with their mouth?), ie, looking and acting like they are heavy and sharp.
Quote from: cron on February 07, 2011, 04:13:50 AM
For everything else, the IMG tag can be used like:
[img width=640]http://some.png[/img]
For what it's worth, I think it should appear that the basi's legs/claws could stab through human legs and feet to grab them (in addition to grabbing them with their mouth?), ie, looking and acting like they are heavy and sharp.
Yeah, I figured that out while you were writing this. And thanks for that idea, I might animate the grab that way. Still, the basi is supposed to be a stealthy creature, with a small profile, and I think those spindly legs work well with that.
I'm poor at modeling.....
But I can animate ;D
i know this is a very old topic, but i remembered, does anyone have the link to download the textures? I could use it if i were to make a trem promo to try to keep trem from dying. Since last year, tremulous has lost about 30 servers on the masterlist, and about 20 players at any time average. [these are my estimations btw]
Quote from: ULTRA Random ViruS on April 15, 2012, 01:03:28 PM
i know this is a very old topic, but i remembered, does anyone have the link to download the textures? I could use it if i were to make a trem promo to try to keep trem from dying. Since last year, tremulous has lost about 30 servers on the masterlist, and about 20 players at any time average. [these are my estimations btw]
Which textures and how are textures going to stop trem dying?
Quote from: ULTRA Random ViruS on April 15, 2012, 01:03:28 PM
[these are my estimations btw]
Cool, no reason to believe them whatsoever.
the posts from the beginning such as the goon texture, rifle texture etc... what do you think? ::)