Author Topic: Welcome to the Rendering Engine Overhaul Project  (Read 39544 times)

0 Members and 1 Guest are viewing this topic.

Offline The E

  • He's Ebeneezer Goode
  • Global Moderator
  • 213
  • Nothing personal, just tech support.
    • Skype
    • Steam
    • Twitter
Re: Welcome to the Rendering Engine Overhaul Project
It is a solid plan. I like it.
**** every cause that ends in murder and children crying. ― Iain Banks
Join the fun at the HLP IRC channel. Get the latest spam and gossip as long as it's fresh!

 

Offline Iss Mneur

  • 210
  • TODO:
Re: Welcome to the Rendering Engine Overhaul Project
Sounds like a plan.

[snip]
Goober mentioned having a list of some of the biggest bottlenecks provided by Taylor
[/snip]
Again this list as been brought up.  Why has this not been posted publicly so that everyone can read it?


Also, if we are going to improve the code, we MUST have a coding style written down so that anyone that wants to contribute code to the engine knows beforehand what is acceptable code.
"I love deadlines. I like the whooshing sound they make as they fly by." -Douglas Adams
wxLauncher 0.9.4 public beta (now with no config file editing for FRED) | wxLauncher 2.0 Request for Comments

 

Offline Goober5000

  • HLP Loremaster
  • Administrator
  • 214
    • Goober5000 Productions
Re: Welcome to the Rendering Engine Overhaul Project
As usual, karajorma is the more diplomatic one. :)  Chief1983 pointed out that I wasn't very tacftful, and for that I apologize.

For the record, when I saw that both portej05 and Hery had left the project, I figured that the project was abandoned and leaderless.  I missed the post where portej05 handed it off to chief1983, and as soon as chief1983 corrected me I apologized to him.  Even so, chief1983 agreed with me that the overhaul project in its current form is a dead end.


Again this list as been brought up.  Why has this not been posted publicly so that everyone can read it?
Taylor has posted it in the past.  But, scanning through his post history, these items come up:

model collision
model animation
sound
pilot file
dynamic limits for ships and weapons
a crapload of bugs that are currently in Mantis

Taylor posted a longer list at one point, but I can't find it right now.
« Last Edit: March 11, 2010, 09:38:47 pm by Goober5000 »

 
Re: Welcome to the Rendering Engine Overhaul Project
Code: [Select]
21:08 portej05 karajorma: You still here>
21:08 NickServ Password accepted -- you are now recognized.
21:09 karajorma Yeah
21:10 portej05 Thank you for updating your post
21:10 portej05 I thought I'd share some of my thoughts
21:10 portej05 Especially before goober goes on a micro-optimisation witch hunt
21:11 portej05 Sound is already a fairly separate system with a not-badly defined interface
21:11 portej05 It can be threaded without much effort at all
21:12 portej05 Define a job queue which effectively represents an inter-thread communication structure
21:12 portej05 Define a sound thread which just loops around pulling jobs off and executing mixing
21:12 portej05 You suddenly remove 90% of the sound engine from the main execution thread
21:12 portej05 (with not a huge amount of effort, I might add)
21:12 portej05 You may not even have to update sound api calls throughout the engine - just redirect the current calls to something like mt_sound* through the thread interface
21:13 zookeeper yeah, looks like it's drawing all faces...meh.
21:13 karajorma The amount of time the game is spending in the sound code seems to change depending on which kind of profiling I use though
21:14 portej05 Still, it's one chunk demonstrating the concept for not a huge amount of work
21:14 karajorma Fair enough
21:14 portej05 Especially given that it's probably one of the better interfaces in the system
21:15 portej05 But can you see why you'd have to freeze development on the feature, even briefly to be able to do it?
21:15 karajorma Not really
21:15 portej05 The interface has to remain stable during the work
21:15 portej05 I don't think I communicated that well enough the other night
21:15 karajorma But that's an argument I've already had enough times
21:16 portej05 We haven't fought over stable interfaces....
21:16 karajorma We have over development freezes though
21:16 karajorma And I'm not doing it again
21:17 portej05 So how would you go about the above then?
21:17 karajorma We can worry about it when someone codes it
21:19 portej05 Who's saying that there isn't someone who has been thinking a lot about how to implement it?
21:21 karajorma Well Taylor is busy with the sound code now, you can always suggest this to him
21:23 portej05 The new sound code is headed for Antipodes - it's almost finished
21:23 karajorma All the more reason to PM him now
21:23 karajorma Best time to work on a new sound code feature is when you've just finished one
21:24 karajorma the code is still fresh in your mind
21:25 portej05 How about I just stick the above on the forum and you can PM him a link?
21:25 karajorma That would do
STRONGTEA. Why can't the x86 be sane?

 

Offline High Max

  • Permanently banned
  • 29
Re: Welcome to the Rendering Engine Overhaul Project
*_*
« Last Edit: May 25, 2010, 11:06:26 pm by High Max »
;-)   #.#   *_*   ^^   ^-^   ^_^

 

Offline chief1983

  • Still lacks a custom title
  • Moderator
  • 212
  • ⬇️⬆️⬅️⬅️🅰➡️⬇️
    • Minecraft
    • Skype
    • Steam
    • Twitter
    • Fate of the Galaxy
Re: Welcome to the Rendering Engine Overhaul Project
Take your FUD elsewhere, we don't want any :P
Fate of the Galaxy - Now Hiring!  Apply within | Diaspora | SCP Home | Collada Importer for PCS2
Karajorma's 'How to report bugs' | Mantis
#freespace | #scp-swc | #diaspora | #SCP | #hard-light on EsperNet

"You may not sell or otherwise commercially exploit the source or things you created based on the source." -- Excerpt from FSO license, for reference

Nuclear1:  Jesus Christ zack you're a little too hamyurger for HLP right now...
iamzack:  i dont have hamynerge i just want ptatoc hips D:
redsniper:  Platonic hips?!
iamzack:  lays

 

Offline High Max

  • Permanently banned
  • 29
Re: Welcome to the Rendering Engine Overhaul Project
*_*
« Last Edit: May 25, 2010, 11:06:17 pm by High Max »
;-)   #.#   *_*   ^^   ^-^   ^_^

 

Online Mongoose

  • Rikki-Tikki-Tavi
  • Global Moderator
  • 212
  • This brain for rent.
    • Minecraft
    • Steam
    • Something
Re: Welcome to the Rendering Engine Overhaul Project
FSO is not going to die some swift, mysterious death without the full-scale implementation of multithreading.  It may hit certain walls in terms of possible performance, but I hardly see how that automatically equates to the developer/modding community shriveling up and disappearing.

 

Offline castor

  • 29
    • http://www.ffighters.co.uk./home/
Re: Welcome to the Rendering Engine Overhaul Project
Like FSO was packed with such power hungry features that nothing else but multi threading helps anymore..
I'd like to hear about *one* feature that would be (realistically) relevant for FSO, but is not doable without multi-threading?

 

Offline The E

  • He's Ebeneezer Goode
  • Global Moderator
  • 213
  • Nothing personal, just tech support.
    • Skype
    • Steam
    • Twitter
Re: Welcome to the Rendering Engine Overhaul Project
Oh, multithreading isn't mission-critical. However, there are aspects of the engine that can be threaded, which would free up resources to use by the main thread. The sound interface, for example. Or asset loading.

In the end, it's a bit of future proofing. If we extrapolate current trends, we can see that there will be only marginal improvements in single-thread performance in the future, as a result, if we want to use the power modern PCs give us efficiently, multithreading is something we should be thinking about.

That being said, as Goober pointed out, there are still areas of the code that can be improved for massive gain without altering the core concepts of the engine; since that is a more realistic goal, it's the one we're probably going to pursue.
**** every cause that ends in murder and children crying. ― Iain Banks
Join the fun at the HLP IRC channel. Get the latest spam and gossip as long as it's fresh!

 

Offline DaBrain

  • Screensniper
  • Moderator
  • 212
    • Shadows of Lylat board
Re: Welcome to the Rendering Engine Overhaul Project
FSO is not going to die some swift, mysterious death without the full-scale implementation of multithreading.


Nobody said that. We're just worried about the future of FSO. For now, it's still 'ok' to use only one core.
The CPU limitation of FSO is quite obvious though.

And no, the CPU load isn't that horrible, when you play FS2.

However, once you put some more complex content in there, some of the outdated parts of the engine really get in your way.
Imagine putting in a fairly complex model into FSO. A really big and important ship and lets say it has 160k polygons.
That's a lot, but really not that big of a deal for any gfx card that isn't completely outdated.

Instead of the graphic system, the collision code will drag the performance down a lot.
The game becomes unplayable when you put many of them into your mission.

Now imagine you have one of those new Intel 6 core CPUs with HTT and only one of the 12 availabe threads in your task manager is at 100%, while all the others are at ~0%.


I think the problem is less FS2, but the mod projects. They need to be able to get more out of the game.


Edit: I hope nobody sees this as a rant. I'm not blaming anybody there and I'm not telling the coders how to do their jobs.
I'm just concerned and I really know that this is not an issue that can be solved easily.
« Last Edit: March 19, 2010, 03:37:26 pm by DaBrain »
--------------------------------------------------
SoL is looking for a sound effect artist
Please PM me in case you want to apply
---------------------------------
Shadows of Lylat - A Freespace 2 total conversion
(hosted by Game-Warden)
----------------------------------

 

Offline Bobboau

  • Just a MODern kinda guy
    Just MODerately cool
    And MODest too
  • 213
Re: Welcome to the Rendering Engine Overhaul Project
is the colision code realy that bad? I always thought it was fairly quick and would scale well to larger models.
Bobboau, bringing you products that work... in theory
learn to use PCS
creator of the ProXimus Procedural Texture and Effect Generator
My latest build of PCS2, get it while it's hot!
PCS 2.0.3


DEUTERONOMY 22:11
Thou shalt not wear a garment of diverse sorts, [as] of woollen and linen together

 

Offline DaBrain

  • Screensniper
  • Moderator
  • 212
    • Shadows of Lylat board
Re: Welcome to the Rendering Engine Overhaul Project
From my experience I can tell the collision detection is currently one of the bottlenecks. Maybe even the worst one.


It also doesn't work very well for big objects.They tend to get holes in the collision.
Maybe PCS2 could fix that, but I fear it might be a limitation in the collision code.



There is a way to use simplified collision meshes, which boosts the performance a lot. (In a test with complex meshes I got from 25-30 fps to 120 fps)
However, it's more or less a workaround. There are still holes in the collision with the simplified meshes.
--------------------------------------------------
SoL is looking for a sound effect artist
Please PM me in case you want to apply
---------------------------------
Shadows of Lylat - A Freespace 2 total conversion
(hosted by Game-Warden)
----------------------------------

 

Offline Fury

  • The Curmudgeon
  • 213
Re: Welcome to the Rendering Engine Overhaul Project
There is a way to use simplified collision meshes, which boosts the performance a lot. (In a test with complex meshes I got from 25-30 fps to 120 fps)
However, it's more or less a workaround. There are still holes in the collision with the simplified meshes.
Care to elaborate on this? How do you create simplified collision meshes? What are the disadvantages?

 
Re: Welcome to the Rendering Engine Overhaul Project
High poly models are good for viewing, but when you don't need the same complexity for collisions.
For example, a sphere with millions of polygons can be represented roughly as a dodecahedron - a massive saving (it's an exaggerated example, but that's the point). You just have to load one representation into the graphics system and the other representation into the collision code.
STRONGTEA. Why can't the x86 be sane?

 
Re: Welcome to the Rendering Engine Overhaul Project
So basically, say, loading detail1 into the collision code instead of detail0?

 

Offline DaBrain

  • Screensniper
  • Moderator
  • 212
    • Shadows of Lylat board
Re: Welcome to the Rendering Engine Overhaul Project
What portej05 said. We only need the vague shape of the mesh for collsions.

It's a very common thing to do in games. In fact, I doubt there games out there that still use all draw meshes for collisons.

Here is an example from the Unreal Engine 2:




And this is an example from SoL.




We made collision meshes for our models. Like I said, the performance gain was incredible, but the holes in the collision remain and even though it's kind of hard to tell, I think they are bigger.


Sushi implemented a feature to turn off collision detection for submodels by simply putting these flag in them.


$nocollide_this_only: If this flag is set, then the submodel it is set on will NOT have collision detection. Put this flag on the high-poly "pretty" version of the mesh.
$collide_invisible: If this flag is set, than the submodel it is set on will allow collisions even for invisible textures. Give the collision model the invisible texture as well as this flag.



So basically, say, loading detail1 into the collision code instead of detail0?


Well, I wouldn't reccomend it.
Yes it would help a lot, but lods are ment to keep up the visual quality has high as possible with less polygons. In terms of collision detection they are still wasteful.
Also they often end up below parts of the lod0 mesh. Think about hit effects. You do not want that. In fact if your collision mesh is slightly above the draw mesh surface it can even improve the visuals, as the hit effects might not intersect with the draw mesh anymore.
« Last Edit: March 21, 2010, 08:22:20 am by DaBrain »
--------------------------------------------------
SoL is looking for a sound effect artist
Please PM me in case you want to apply
---------------------------------
Shadows of Lylat - A Freespace 2 total conversion
(hosted by Game-Warden)
----------------------------------

 

Offline Fury

  • The Curmudgeon
  • 213
Re: Welcome to the Rendering Engine Overhaul Project
Does FSU models use this method?

And why is this the first time I hear of this anyway? If this has such huge gains, why it is not used widely in FSO models?

 

Offline DaBrain

  • Screensniper
  • Moderator
  • 212
    • Shadows of Lylat board
Re: Welcome to the Rendering Engine Overhaul Project
No, FSU isn't using this yet. It's a little bit complicated to add collision meshes to existing POFs.

With a few tweaks in PCS2 that might not be an issue in the future. *



As long as we still have holes in the collision, I'd advice to stick to the current system.






* Importing another POF or even DAE works very well, but it's has to use the "invisible" material. You can add new materials/textures, but you can't assign them to a mesh... New textures won't be imported either.
--------------------------------------------------
SoL is looking for a sound effect artist
Please PM me in case you want to apply
---------------------------------
Shadows of Lylat - A Freespace 2 total conversion
(hosted by Game-Warden)
----------------------------------

 

Offline Fury

  • The Curmudgeon
  • 213
Re: Welcome to the Rendering Engine Overhaul Project
If SoL is using this now, does this mean PCS2 and collision detection will be updated in the near future? Or why is SoL using it when you say it's not recommended yet?