rd-rend2 (old thread)

[DT.]

objects (32) per model

[ensiform]

Yea and what exactly is that code wise.

[DT.]

No idea, but I have been told in the past (don't remember who) that there is an object limit in the code. But what really confuses me is, if there is a 32 limit then why does my Jedi HM model work when it has well over 32 objects? Maybe the limit doesn't do anything or maybe the info I was told is wrong.

[Exmirai]

How about move fx system into renderer 

[Xycaleth]

What benefit would that provide?

[Exmirai]

custom fx system?

[Xycaleth]

What do you mean by custom fx system? We can already customize the fx system.

[Exmirai]

Files: FXExport.cpp, FxPrimitives.cpp, FxScheulder.cpp and FxSystem.cpp are located in ojk.exe, not in renderer :\, can we move it?

[ensiform]

What purpose does moving them into the renderer solve? They don't actually do any sort of rendering.  It just makes basic calls to the export system.  Don't want to bog it down with even more bloat.  The font and language code is still in there and doesn't need to be per-se as it is.

[Futuza]

Yeah I'm not really understanding why you want to move things around/what you want to accomplish?

[Exmirai]

I Want to add PhysX/Apex Particles system and Turbulence 

https://developer.nvidia.com/apex-turbulence

[ensiform]

And those things have absolutely nothing to do with the renderer.

 

Additional addendum: PHYSX SDK (and specifically Apex portions) is not GPL compatible.  Therefore not permitted to do so 

 

https://developer.nvidia.com/content/apex-sdk-eula

[Exmirai]

So there will never be a good physics? 

[Stoiss]

there was some talking when OJK was started to add bullet physics engine is this still a feature plan there is beeing thinking about ?

[ensiform]

We aren't planning/going to add any 'good' physics no.  And certainly not in a renderer.

 

Not of the main scope of OpenJK.

[Xycaleth]

I'm not sure we managed to get from moving the efx (I.e. Particle system purely for visuals) to meaning you would get better physics ;p

 

In other news, I'm procrastinating from doing the weather system by making some optimisations which should give a nice performance boost. Should be done within a week or so

[ensiform]

I'm not sure we managed to get from moving the efx (I.e. Particle system purely for visuals) to meaning you would get better physics ;p

 

So there will never be a good physics?  

[Futuza]

So there will never be a good physics? 

Nothing is stopping you/someone else from implementing it yourself in a separate branch though.

[Raz0r]

WRT anti-aliasing, you don't really need beyond 4x to be honest. Unless you like counting in seconds per frame instead of frames per second

[Xycaleth]

Everyone should count in seconds per frame

[Xycaleth]

Great success: I've finished writing the code for the performance improvements!

 

The bad side of it is that I now get 5 frames per second on FFA3 So I got to find where the bottleneck is now.

[minilogoguy18]

[source]

Any possibility of SMAA being added as an antialiasing option?

 

https://github.com/iryoku/smaa

[Xycaleth]

Any possibility of SMAA being added as an antialiasing option?

 

https://github.com/iryoku/smaa

 

To quote myself from earlier:

 

No need, we can use MSAA.

 

There's pretty much no reason to use any other anti-aliasing technique except for MSAA unless you can't use MSAA (if you have a deferred renderer instead of a forward renderer).

 

MSAA is Multisampling Anti Aliasing. Reading the SMAA page, it says:

Finally, the technique has been specifically designed to clone (to a reasonable extent) multisampling reference results.

So why clone the results, when you can simply produce the correct results in the first place?

[source]

It achieves nearly the same thing while giving almost no performance hit. Not a big deal in a game as old as this, but hey. Not everyone is running a GTX 770 like myself