Create an account


Thread Rating:
  • 1 Vote(s) - 3 Average
  • 1
  • 2
  • 3
  • 4
  • 5
How good is darkplaces really?

#26
I decided to use F.E.A.R as a comparison because it is clearly a BSP game (instead of a sandbox like everything else these days) PLUS a new F.E.A.R is coming out.

I think we can easily reach the FEAR 1 standard
http://www.youtube.com/user/fppgames#p/u/1/3gVavkuE5Bw

FEAR 2 is what I think should be our standard
http://www.youtube.com/watch?v=gVqT83Lw7...re=related
Just a little physics, higher production quality but nothing really we don't have in Darkplaces.

FEAR 3 i'm not sure about. Could be Unreal 3 but still looks BSP to me. Takes the gritty art style for sure.
http://www.youtube.com/watch?v=JgYG2Bx-iwk
Just skip to the footage.
Reply

#27
if it wasn't toooooo late i'd say we should use Unreal Engine 3 Big Grin Link
MY NOOB STATS:
[Image: 788.png]
Reply

#28
(08-22-2010, 09:51 PM)Cuinnton Wrote:
Quote:Just 6 character artists, 6 concept artists and as many as 30 environment artists! I think we need much bigger teams for making maps!

Luckily I'd say the majority of the contributing community are proficient using netraident. Although I agree entirely the methods used to contribute maps are completely unorganised.

Great map making for Xonotic requires 3 stages of development, by people assuming 3 different positions. This is waht I have found to be a great method for producing high quality maps, and sharing the work load between members. It is also a self quality assuring system, with only the best levels being worked on.

1) Mapper: makes a level, with varing levels of quality of layout, theme, optimisation or visual apearance. Levels becomes popular due to high quailty layout. Which is often the case as levels that are just visually pleasing are played for a few weeks and don't catch on. This role can be done by any contributer in the community, although this is a great position for those new to mapping.

Possible examples:vede, MintOX, Grasshopper, Cortez666

2) Dev: Skilled mapper identifies good layout and increase visual appearance, optimises resources, and alters the theme to suit Xonotic. This is done primarily by dev's. Dev's are very busy with commitments to other areas of the game so there time and resources are scarce. This is good because there limitations of time becomes a type of quality control, with only the best levels being selected.

Possible examples:FruitieX, MireaKitsune

3) Detailer: Highly skilled mapper which contributes to Xonotic by primarily mapping. Paying an attention to detail, mainly increasing the visual appearance of the level. Once complete, the detailer passes the level back to the dev for final optimisations and submission. I like to take this role in level construction because it allows dev's to spend more time on other parts of the game. Smile

Possible examples:Cuinnton ?????

If people assumed these roles, we could get mapping high quailty much more organised! I would also liked to see more Mappers assume the postion of Detailers!

I like this mapping in "stages" idea. I think this is truly the best way to achieve high quality maps. We should adapt this idea for official maps into the first stable release, really. Smile
(beta isn't as important, because we must get something out there that people can easily playtest maps/gameplay with as soon as possible!)

I propose these stages during map development for Xonotic 1.0:

Stage 1: Here I'd put the most emphasis on layout and item placement, visuals don't actually matter much at this point as long as the map remains playable (too dark is not playable, half made out of caulk is not playable) Tongue
As you said the layout makes the map, if it sucks the map won't get played no matter how good it looks. So this is where playtesting takes part, and possible modifications to the map/item layout! A good layout is interesting, varying, flowing etc. Layout MUST be optimized for excellent gameplay at this stage for the map to proceed to the next stage, also has to be approved by a majority so we don't waste time adding nice visuals to a bad map.

Stage 2: should only consist of optimizing the layout for best possible VIS, because layout changes are likely necessary here and they are unwanted once we have details/finished texturework on the map. With good VIS, more details can be added since those details won't be visible from other rooms. That's of course a challenge on it's own on open maps, which is why we should IMO restrict official maps to mostly indoor parts... Besides indoor environments look better with less effort at least from my experience (dp never really was made with huge outdoor environments in mind anyway?)

Stage 3: by now the layout is mostly final. Theming the map with basic texturework takes place if good texturework isn't already there. Some good light placements can be thought out, but a detailer in stage 5 is free to move these around.

Stage 4 & 5: (shifts between 4 and 5 often)
4: a texturer adds more texture details to the existing base (trims, shaders and whatnot). The texturer might create map specific textures now and modify existing textures to fit in better, and e.g. add wear on the edges of textures at a suitable size. If coming from stage 5 the texturer can create specific shaders for details (e.g. metal handrails with fake reflections)
5: then the details come in, possibly simultaneously as stage 4. Detailers are of course allowed to make small changes to the layout, but then the affected parts have to be run through stage 2 again. The detailer should make sure to playerclip details that possibly are disrupting gameplay/map flow. Move back to stage 4 if a texturer is needed, e.g. to add rust on a wall near a detail or such. It's also the detailer's responsibility to place lights into sensible places WITH a clear light source behind it, because a light without a light source looks silly and unrealistic. If that has to be done it should be left for stage 6 to keep details still easy to modify.

Stage 6: Final lighting. "Fake" lights can be placed to fake diffuse lighting, and tweaking q3map2 light parameters takes place + other weird tricks to circumvent q3map2 suckage where needed.

Stage 7: Radarmaps, mapinfo, screenshot

Stage 8: Profit!

Now, if only this system would work... * thumbs up *
Links to my: SoundCloud and bandcamp accounts
Reply

#29
(08-25-2010, 10:36 AM)rainerzufalldererste Wrote: if it wasn't toooooo late i'd say we should use Unreal Engine 3 Big Grin Link

Hmmm... why not XD

I think the devs get angry, if you tell them to change the Engine Big Grin
Reply

#30
I would do it if I wouldn't know that someone did it yet...
...and FAILED!!! *DAM DA DAM DAM DAAAAAM*
MY NOOB STATS:
[Image: 788.png]
Reply

#31
(08-25-2010, 11:13 AM)pyr0 Wrote:
(08-25-2010, 10:36 AM)rainerzufalldererste Wrote: if it wasn't toooooo late i'd say we should use Unreal Engine 3 Big Grin Link
mmm... why not XD

It is not free, open source software, which is one of the goals of Xonotic as far as I know.
Links to my: SoundCloud and bandcamp accounts
Reply

#32
Link!
http://udk.com
It seems to be free, but not open source :S

UDK.com Wrote:Who's it for?
Anyone. Everyone. You. Unreal Engine 3 has been used by game developers, researchers, television studios, machinima directors, artists and students. If you have an idea that needs to be brought to life in a game engine, UDK is for you.
MY NOOB STATS:
[Image: 788.png]
Reply

#33
IMO, if Xonotic would use the UDK it could be a huge step forward cause there are much
more devs/artists who already knows the UDK and worked with it. Just watch moddb.com

But as it has already mentioned, it's not open source.
Not even "Free Software" like DarkPlaces.

But Darkplaces is doing well at the moment Tongue
Just a matter of what the artist/mappers are able to create. Smile
Reply

#34
Forget changing engines. It means recoding ALL the game code to something else than QuakeC + DP extensions. It probably also means changing the formats of a lot of media assets.
[Image:http://i.imgur.com/4XODR.png]640K ought to be enough for anybody.
     ― Linux Torvalds
Reply

#35
We are NOT changing engines (ask ANY dev) and that's not what i meant this thread to be about. All I really want to know is what the practical limits of darkplaces is.
I personally think Nexuiz is a poor example of what darkplaces can do but i'm not a dev so i don't know. It's probably a blast to frag in but, seriously, what am i looking at here? Where are these places?
[Image: dm-11128069372314.png] [Image: dm-4127689989313.png] [Image: dm-6127672310414.png] [Image: 4p605cy7pwr11dz37mvx_thumb.jpg] [Image: dm-612824142815.png]
Sorry to spam the shot but the last one is the same game with just a little attention to aesthetics.
Reply

#36
What's your question/statement about those screenshots exactly? I didn't understand your message :x

Those are xonotic screenshots, #1 and #3 are from g-23, #2 is from red_planet. The two others, I don't know :X
[Image:http://i.imgur.com/4XODR.png]640K ought to be enough for anybody.
     ― Linux Torvalds
Reply

#37
In a single line: 1,2,3,4 looks crap and 5 looks amazing, but is 5's high quality going to drag DP to a grinding halt?

Or?
"Yes, there was a spambot some time ago on these forums." - aa
Reply

#38
(08-25-2010, 10:36 AM)rainerzufalldererste Wrote: if it wasn't toooooo late i'd say we should use Unreal Engine 3 Big Grin Link

NOT GPL COMPATIBLE
ECKZBAWKZ HUGE LIST OF ACHIEVEMENTS GOES HERE....


Oh wait.
Reply

#39
(08-25-2010, 04:45 PM)PinkRobot Wrote: In a single line: 1,2,3,4 looks crap and 5 looks amazing, but is 5's high quality going to drag DP to a grinding halt?

Or?

Well 3 and 4 are a bit sub-standard, but 1 and 2 arn't bad. Just because 5 looks like a boring FEAR/Doom3 clone you think it's awesome?
Reply

#40
This discussion is very interesting to me.

I think that we should really make an effort to make Xonotic not only the prettiest open source game we can manage, but also a game that can compete with modern games visually. I know that shininess isn't supposed to be the main goal of Xonotic, but we already know what the gameplay will be like. Unless we plan to revolutionize the whole concept of deathmatch gameplay, then I really think that pushing forward in graphics as much as we can is one of the best ways to avoid being Yet Another Deathmatch Game (and personally, I'm kinda sick of the overt sense of stagnation in open source games graphics-wise... I don't want to just wait for id to open the idTech 4 source up to see the next big jump in engine capabilities. What'd be really kickass would be if they opened idTech 4 to the open source community and it was actually behind what was already available), and I think that this is something we should at least get a grip on in the early stages, to allow mappers and such to plan a bit ahead for features that we might be expecting to appear later. I don't like the idea of putting that off "until all the other stuff is done" because when all the other stuff is done, we'll have all the other stuff done and adding new features to the game will require too much reworking of all the other stuff we have done. We should try to actually discuss some things we think can be done to improve the engine, AND I think that we need to try to more encourage the use of this sort of mapping-in-stages system for all assets (except music?). I know it can't be done ALL THE TIME (I understand the concept of suddenly being accosted with such an awesome, fleshed out idea that you just have to do from beginning to end, but if we do everything by relying on sudden inspiration, I think this will go very, very slowly), but it might be interesting (and fun) to have regular "okay let's make a map" collaborative mapping threads. (Same with weapon models and player models!) We should try to scour the webs for screenshots or photographs of things that we think look nice and then try to find exactly what makes them look nice. (This is actually what I did on Concourse, and from the feedback I got, it's apparently pretty nice-looking for a first map.) This SORT OF happened with the "inspiration for..." threads but this not meant to just have a bunch of pictures to give people ideas (which is a very good idea, and it works beautifully for giving people general concepts to build upon), but this idea is meant to be about figuring out what kinds of things can be done to really fine details to make larger things seem much prettier than otherwise. (Not to COPY ideas, but sort of like "inspiration for fine details" but we'd need to extract inspiration from larger images.)

Sorry if that was a bit too stream-of-consciousness to be clearly understood. I'll try to condense it to get at the highlights for understandability.

Things that I've come to think could be good for this project:
  • Asset development involving more than a single person starting very early in creation, if not before even ANY creation has started at all yet ("Okay, maptiem, what sort of overall layout should we think about?").
  • In-depth discussion of images of things that seem to look very good, in order to see what kind of small detail ideas are currently missing from Xonotic's content that could be added to make it look better. (Similar to the sudden emergence of those nice-looking safety rails, but with more than just safety rails.)
  • Discuss things that can be changed with the engine to increase performance on more advanced features, or to implement new features. (NOT "before all the other stuff is done"!)

So yeah. That's basically my current thoughts on this. If I'm not the only one who thinks this way, then I'd be totally willing to try and get the ball rolling on a couple of the ideas and see if the result is good enough to consider doing it more often or not.
Reply

#41
All true, but in the end it boils down to if we have artists (and coders) capable of pulling it of (meaning both the skill and the time). And I think while Xonotic has an amazing group of contributors already, it is not going to become much better just by managing everything a bit different and having community discussions (in fact the later can also be a distraction and lead to bad "design by committee" results).
Reply

#42
(08-25-2010, 04:45 PM)PinkRobot Wrote: In a single line: 1,2,3,4 looks crap and 5 looks amazing, but is 5's high quality going to drag DP to a grinding halt?
Or?

My point is it's not a lot of polys! It runs on my EEEPC!
I never released it before because it isn't near the quality it could be. It's totally incomplete but i think it could be useful now. PLEASE use and add to or create a GIT branch or something!
Try it yourself by downloading ihsan.pk3 (temp hosting)
Type "map hires" in the console for the test map shown there.
Type "map test" in the console for basement with handrails everywhere.
There are some PSD's in the ihsan_copied folder (i don't have the main one i used for nearly all the metals on this comp Sad ) and map files are all there. GPL yadda yadda yadda....
Reply

#43
Low poly doesn't mean ugly either, UT99 has somewhat of a cult of mappers that make their maps as low poly as possible (lower poly than that decade old game's stock maps!) and they still come out looking amazing (look up low poly map packs). Hehe I remember one of their sigs on a forum said something like: "hmm that brush only has more polys than any map I ever made" or something like that. Remember, resources and tools can only be as good as whoever is using them. Using almost nothing a few elites can probably make something that looks better than a semi-skilled person with more tools/resources to work with.
ECKZBAWKZ HUGE LIST OF ACHIEVEMENTS GOES HERE....


Oh wait.
Reply

#44
O_o those low poly maps are amazing, I was looking at HOLP.

Ihsan, here is the gist, this game shouldn't be designed to look amazing on a netbook, even my ION GPU in my netbook shouldn't be able to max Xonotic. The better a game looks, the more resources it requires. Optimization can temporarily reduce this factor, but there is a limit. For an EEE PC with an ION, you can reduce the poly count, use normal textures, and enable normal maps, gloss, and bloom...plus maybe poor reflections. But to make the game look good(i.e. that first shot of G-23 you posted) you have to have the capable hardware. I'm not sure what the issue is, the game looks great, and I am a hardware/realtime enthusiast. To me, UT3 looks okay, but does not feel real. Crysis looks decent. CoD6 MW2 looks horrible...as does BO. On the other hand, Raytracing looks amazing. But DP is in no way inferior to UT3, in fact, it sports better features than UT3. In my opinion, they are closely tied. It ain't Crysis, but this team also isn't comparing DP with raytracing and basing the engine upon it. The game looks fine, my only quip at this point is performance, especially with dynamic lights on objects(weapons etc.)
Reply

#45
Ihsan thank you very much for the textures. I'll create a branch for them called diabolik/ihsan.
Reply

#46
I was only trying to figure out what Ihsan meant with the screenshots, in response to MrBougo. I even quite like rough brushwork myself. But feel free to ignore me, because I will also miss the old player models Smile

If Xonotic could merge 5's quality and detail with Nexuiz crazyness, it would probably become the best FPS game ever Big Grin
"Yes, there was a spambot some time ago on these forums." - aa
Reply

#47
Ihsan I was wondering if it would be possible for you to make your texture set 512x512?
Reply

#48
Only 512x512 ?!
I thought the requirements for inclusion where 1024 or even 2048, I forgot, but I don't think 512...
[Image:http://i.imgur.com/4XODR.png]640K ought to be enough for anybody.
     ― Linux Torvalds
Reply

#49
(08-26-2010, 04:17 AM)DiaboliK Wrote: Ihsan I was wondering if it would be possible for you to make your texture set 512x512?

Some of the textures are 512x512 already but keep in mind that this isn't a texture pack yet, just me experimenting with darkplaces. Now that i look at the pk3 there are a good bit of textures there which i think fail. Just drop the garbage textures and we can improve the ones which work.
Reply

#50
Mr Bougo the trak set is 512x512 because it is very good. If the quality is high enough 512x512 is ok.
Reply



Possibly Related Threads...
Thread Author Replies Views Last Post
  Trying to understand darkplaces source code wiefie 37 5,139 09-22-2017, 01:37 PM
Last Post: Lyberta
  Module (music) support for Darkplaces (again) [test it] nilyt 8 4,939 04-21-2015, 08:24 PM
Last Post: BuddyFriendGuy
  darkplaces wiki down .... hutty 4 4,854 10-13-2012, 09:47 PM
Last Post: hutty
  Parallelization of Xonotic (and Darkplaces engine) Sarge999 19 14,535 11-21-2011, 03:22 PM
Last Post: Sarge999
  [SOLVED] Compiling from GIT fails: darkplaces unfa 10 10,531 06-20-2011, 07:58 AM
Last Post: unicornsteak
  Darkplaces Code master[mind] 3 4,030 11-28-2010, 05:02 AM
Last Post: SavageX

Forum Jump:


Users browsing this thread:
1 Guest(s)

Forum software by © MyBB original theme © iAndrew 2016, remixed by -z-