I was playing around with the new no thing limit, and made a mildly amusing level.

Check it out if anyone cares.

screens?

My goodness... That is alot of people. I tested it with my MAD mod, with strifle, and wowee... That is way too many objects... FRAMERATEKILLER! Fun....

/Edward

Pretty fun with Edward's beta. I really racked up the kills...

I tested it with another Mod of mine... These became GAME KILLER! If you wish to experience a framerate of 0.0001, then click me attachment.

/Edward

What we need in the hud now is a kill counter with at least 10 digits. Death rates will go up in jk from now on.

Thus why the RVTCS is still needed. Before the thing limit was "broken". it was already possible to have up to 640 things rendered at any given time (320 by default). Which was already way more then enough. There's a reason why you see few games found on store shelves today that feature more then 320 objects being rendered at any given time.

I must disagree. The RVTCS only does that because it forces the mapper to space out the objects. Common sense and self control is what is needed now.


This is perhaps the single greatest advancement in JK editing. Ever. And while it is quite possible that the misuse of it will result in bad framerates, I am sure most are willing to take that chance. Besides, noone, and I mean noone wants to spend the unholy amount of time it takes to implement a TCS.

Unless this "patch" automatically destroys 3do's at predetermined distances (and adjustable by the editor), it's useless. An RVTCS will still be needed to handle that.

Not to mention that with the latest build of the RVTCS you have a built in LOD system that (if used properly) can far exceed the limit of 4 that JED/JK gives you by default.

This was the purpose of the RVTCS. Not to break the thing limit, but to provide an optomized way of rendering a large amount of 3do's in an open 3-D environment.

Not to undermind the achievement, I just think that there were better things to want to patch then the thing limit, IMO...

Holy crap. Optimism.

I think that with this broken limit, it may even be possible to fake some things in JK that many new games can do... and personally I like dealing with JK's templates much better than Quake-based entities, and JK has no problem keeping track of thousands of things.

I also like the 0.5 second compile and load times with JK then the insane lighting and vis calculations with Quake-based games, which I don't think look all that great anyway.

He has a point here. You'll seriously drop the framerate down the drain, if you build a "one sector rest 3do" level and stuff a lot of things in it, cause JK will render every single thing - even if it's blocked by 3do architecture - when it's in a sector that can be seen by the player.

... The main use probably won't be for large 3do based levels. But the 3do thing limit was a HUGE problem. An example would be a level I'm working on. It'll consist of a large city, with many buildings, each with various office 3do's etc in them. Even though they wouldn't be all rendered at the same time (dozens of different sectors...), it just wouldn't be possible to have them all exist at the same time. As that would easily break the 640 thing limit. Having more probably wouldn't slow things down a great deal in that case though, as only a handful would be rendered at a time. Let alone be doing anything (static objects, mostly). I suppose in the case of "one sector" levels, which I personally will never ascribe to, yes, it'd hurt the framerate to have more than 640 things at once. However, not all level editors create one sector and put 3do's in it. (That's what you're forgetting Friend14)

I didn't forget it, it's simply not a factor. If you use multiple sectors, it simply means you have to use a flicker cog. Still doesn't negate the point I was making.

To not use the RVTCS in 3do based enviornments would be foolish.

To have more then 320 things rendered at a time would also be foolish (for instance, if you have trees in your level, try to make a generic patch of trees and export it as a single 3do).

You also have to keep in mind that not everybody is running a 3Ghz CPU with a GeForce 6. The other great thing about the RVTCS is that it's scaleble, meaning that you can change the rendering distance as needed (which amounts to being able to release a low, mid, & hi end graphic versions of the level).

Again, I think it's great that the thing limit has been "by-passed". I'm simply speaking from experience when I say that not using the RVTCS for optimizing is foolish. AND, since there's really no need to have more then 320 things rendered at any given time, it will save the file size by not including this "thing limit by-pass" patch. Basically, I'm just asking all editors to play it smart and keep the end-user in mind....because they're the ones that rate your level and give you praise for all your hard work.

"I didn't forget it, it's simply not a factor."
Completely wrong. Major factor. I understand your point of view comes from your levels being large open sectors with the levels themselves being 3do-based.

What your ignoring, is only things with origins in a sectors origin whatever visible, are rendered. IE, I can have 3 sectors, 1600 things, and have only 1 or 2 rendered. But, the important factor is, those other 1600 would still exist, doing their different things. The number just came from seeing pics of Daft's experiment.

"This was the purpose of the RVTCS. Not to break the thing limit, but to provide an optomized way of rendering a large amount of 3do's in an open 3-D environment."
"The other great thing about the RVTCS is that it's scaleble, meaning that you can change the rendering distance as needed (which amounts to being able to release a low, mid, & hi end graphic versions of the level)."

By this, you're talking about 3do based levels. What I'm pointing out is, NOT ALL editors do 3do-only levels.

"To have more then 320 things rendered at a time would also be foolish (for instance, if you have trees in your level, try to make a generic patch of trees and export it as a single 3do)."

This is not the point of the patch. It is to allow more than 640 things to EXIST. Not be rendered.

"If you use multiple sectors, it simply means you have to use a flicker cog."

... Uhm, no. The only reason to use a flicker cog, is if you have a large 3do which is disappearing in some sectors. Certainly not a factor. If you can't see the sector, it's 3do's WILL NOT BE RENDERED. But the "things" will still exist.

"JK will render every single thing - even if it's blocked by 3do architecture - when it's in a sector that can be seen by the player."
Minor correction, render every thing that's within the FOV of the player, in sectors seen by player. (Engine's smart enough not to render the things behind you... or off to the side where they couldn't be seen.)

An example of a possible use. (WHICH... RVTCS could never handle, or allow.) Suppose, you had an effect, you enter a certain sector, and a "particle" effect is started, creating a rotating of sphere of "particles". Each particle being a seperate sprite thing. Say, 175 surrounding the player, rotating. There are four such sectors, connected by hallways which make a u-curve away from them. (IE, you cannot see the other such sectors from any single one). And all four player's enter the sectors, and the things created are not local. (Ie, on each comp, 175 things created per player) (700). The rendering would suffer so much for any one player, because 175 or so things only were being rendered... if that. Yet it'd be impossible in normal JK.

I've attached an image. When you enter, there's no problem with framerate... There are hundreds upon hundreds of stormies in the other sector though. They exist. But they will not hurt framerate when you first enter. Why? Only the player and 1 storm thing would be rendered. If you entered the other room, yes framerate would drop. But if the same number of things were spread through several rooms, over several hallways(turning at various corners), the framerate would also be fine.

The thing is, the goal isn't to have thousands of things being rendered at once, but to allow hundreds or thousands to exist at once.

That's all fine and dandy until you hit MP and the whole FOV thing goes out the window. What about 3do archi? One could fire a shot which is blocked on one side, and someone else has it go clean through it because it's not in that player's FOV.

I love this. You're both right. LKOH_SniperWolf is right for mainly indoor architecture, Friend14 is right for mainly outdoor environments. The thing limit patch could actually IMPROVE the RVTCS in a way that I'm sure GBK would LOVE. The editor could place in all the objects he wants where he wants them, then throw in a couple (new) RVTCS cogs which then get all the position/template data INGAME rather then in the editor. It would save the editor from almost ALL the hard work from an RVTCS while giving the same effect. (there is always a possible framerate drop at the beginning when the data is being processed before deleting objects, but after that it wouldn't seem any different than the current RVTCS) The coding should be rather simple to add to the current RVTCS if you ask me. GBK you want to take a crack at it?

Rendering and colliding/existing are two different things. So I'm not sure what you mean by FOV.

This is a potential problem with the RVTCS. (Things outside a certain range of the player don't exist at all, and therefore, couldn't collide with things).

However, with normal, level placed things, this would not be a problem. The things would still exist, and therefore, JK would still find whether they collide or not (Even if they aren't being rendered.

(This effect does actually exist somewhat anyways, due to lag. I've seen rails fired which appeared to miss their target (fired by others), yet someone falls dead. ) This is because on the comp of the person who died, they did get hit. While on the others it seems that it missed. (FireProjectiles creation is synced, but not their effects (collisions, etc)) (The evidence of this is just in normal game, fire a rail at a running person, you see it explode hitting them, yet they get no damage, cause on their comp, it missed them...)

(I do understand Friend14's particular point, I'm just trying to point out, it's rather limited, and there are many, many useful possibilities for this patch, over RVTCS. Nor am I putting downthe RVTCS. It's not so much external architecture, as solely 3do-based levels (ie, no sector architecture).)

Yeah right, show me a commercial engine that renders visuals outside the FOV of the player...sheeesh.

So that JED's responds time is increased to about 4 sec or so? And what's the point? You've admitted that it'd have bad frame rate if you entered that room. Why not use the RVTCS to render only the first 200 or so that's within a pre-determined distance from the player? It's not like you can see the other 800 behind them anyhow. You can then have the other 800 render as the player moves further into the room. The RVTCS isn't only for large, outdoor, one sector levels. It's also for interiors that have way too many 3do's.

[/b]

Who still uses particle effects? I'd suggest using well textured 3do spheres instead. If you use the +Adjoin flag 'blocks light' and the Things flag 'prelit' (and making sure that 'architecture is not flagged) you'd have a much nicer effect...one in which the effect would react to any dynamic lights you may have placed in the level. Which you can also adjust how much it reacts to the light (shadow wise) by adjusting the EXTRA LIGHT value on the surfaces of the 3do. 0 = light reacts absolutely with it, 1 = light reacts realistically with it (you can increase this until it is fully lit if desired...even allowing it to be a source of light). It depends on your level. In most cases you'd want to use 1 (where it is understood that the thing would recieve a bit of reflected light from the walls. Where as if you were doing a space level, you'd use 0 (or a value close to it, as your not recieving reflected light on the dark surfaces.....I'd use 0 for non-atmospheric 3do's and 0.25 for 3do's with atmospheres).


SG-Fan, true that it would be nice to place all of the 3do's in the map and be able to test it before implementing the RVTCS...but then again, can you really test a level with a FR of 2? The thing limit forces moderation on the part of the editor...at least as far as how many objects is placed in the level in JED at any given time. You don't want a high responds time because of all of the things JED is trying to render...that makes editing very frustrating. And to top it off, you don't have to fool with a patch.

Maybe in 2 to 3 more years when everyone has at least a 3Ghz CPU and a GeForce 6 this might be nice...but until then, I stongly urge editors not to use it. ESPECIALLY, if you're a new editor.

I don't think he was talking about JK particles, but particle systems in general. And he's right there. With the thing limit broken, you can finally have realistic smoke or fire, using several hundreds timed "3do sprites" as particle system.

You're explaining to GBK the purpose of the system he designed...?

First of all, I was speaking to everyone.

Secondly, I designed the RVTCS based off of GBK's original TCS. GBK coded the RVTCS for me. In fact, every change from v1 to v3 was designed by me. GBK was kind enough to code it for me. Even knowing that I believed in sharing openly any JK discoveries or cog systems with the public, GBK still came to me to ask permission to post the code to the public for the first time.

Friend14: You're right in certain circumstances. Everyone here has admitted that. But you refuse to think outside that box and meet them halfway. Why are you so stubborn on this? The TCS you're talking about would work GREAT on levels that were mostly outdoors and surrounded by pine trees...although with no limits, I think I would set the distant objects to 'not rendered' rather than flat out destroying them, because then shots fired between the trees would still land properly.

I'm not sure what effect that would have on framerate though, I'd imagine it would be neglibile since the stormies in the example posted are obviously 'not rended' in the other sector.

Also on the stormie example...do you really think it would make sense for 200 storm troopers in the background to just 'disappear' for the sake of framerate? No. But that example was more an example of what NOT to do. A good level editor would never release a level that had 12000 storm troopers in one sector because it would suck.

The point is, this little exe hack is essentially correcting a bug. The only reason that LEC put the limit in the first place was because they wanted to keep the sys requirements tight. Or they were lazy. And I'm sorry...but I'm not going to let the fact some guy, somewhere, is still playing this game on his pentium 90mhz with 16mb of ram keep me from being able to do some advanced stuff. And you know what? If the level editors are careful with their setups, it probably will run fine anyway.

You're really missing the point. The framerate won't have to be two, even if you have 5000 things in the level. Those 5000 things can exist, but not all be rendered at the same time. That wasn't meant to be a realistic level, it was just showing that the framerate would not drop when the player is in that initial position, because those other 300 are not rendered. In a more realistic level, as I stated, those would be spread over hundreds of rooms. A similar case would be a city level. 24 buildings, each with maybe 50 objects in them. This well exceeds thing limit, but framerates should never be a major problem, because only 50 or so objects would be rendered at a time.

And I did not mean JK's particles, but a sprite based particle system.



Actually, even on my crappy, aged computer, Jed handled it just fine. Having 300+ things existing didn't slow JK a bit either. 800 mhz. No GeForce, a 1mb processor video card.

I'm not being stubborn. I'm simply doing what I've always done in the Editing Forum, which is give advice and caution to new and old editors alike. The RVTCS is good for both indoor and outdoor levels. In case you haven't figured it out, the RVTCS is actually a 'primitive' culling system for JK.

[

The point is not what happens in the sector with only one stormie, but what happens in the sector with the 1000 stormies.



Actually, I said the back 800 would not be rendered. But I agree, it was a poor example as it isn't very praticle.



Again, I'll reiterate that few games on the shelves now have over 320 objects being rendered at any given time....let alone 640 (the max without patching).



Um, okay, good, cause I wasn't sure what your point was with that example in the first place...or at least how it to pertained to optimizing framerates.



That's fine, but what if one of your rooms was rather large? Or what if you wanted to create the room out of 3do's with 3do objects in it (so that you don't have to worry about the adjoin limit)? The RVTCS again comes in handy. Not to mention, here again, you wouldn't have to fool with including a patch with your level.



You'd have to use thousands of 3do's to achieve I higher effect then you could using surfaces to represent the particles. If you look closely at the games on the shelves today, smoke and fire is ussually made using textured animated surfaces, rather then a particle system. Primary reason? Less time consuming. Secondary reason? Produces higher performance.



Depends on how detailed each object is. Trees and/or elegant furniture are generally much more detailed then a stormie or a strifle. The only work around is switching over so that things are rendered as boxes rather then wireframes...but then you become more dependent on the 3d preview and you start increasing the time it takes to do simple tasks (such as object placement).

No, it wasn't. At least not for me. But then again, I like to add all these little useless details, like food and drink and stuff for a sense of realism.

You've missed the point. I'm speaking from the stand point of frame rate. The RVTCS allows, without patching, up to 640 objects to be rendered on screen at any given time...which is more then enough.

Again, I'll reiterate, the RVTCS wasn't designed to get around the thing limit and that's not what my argument is about (beyond avoiding fooling with an anoying patch). It's primary design was to have a 'primitive' culling system for JK. Getting around the thing limit was mearly a bonus.

Didn't say 3do's, said sprites. (I did, at least) And a couple hundred (or less) would be sufficient for most effects. Surfaces would be very limited. You can't really have a smoothly expanding particle cloud with surfaces.

Games on shelves today use particle systems for smoke and clouds, if you read engine details. Why? Better effects. Textured animated surfaces are relatively 2d. The 2 main methods are volumetric rendering effects, or particle effects. Pixelmatic and U2 engine derivatives rely on particle systems, if I remember correctly, while the Q3/D3 engines use volumetric (and minor particle effects, I think). I'm not sure on console games. I'm aware though that the MGS games use particle effects.

I must disagree here.

...why would you have to delete things to up frame rate by not rending them...when they aren't even being rendered in the first place? In the average indoor level, you're not going to run into 800 storm troopers on the screen at any given time unless that is what the editor intended. You can delete the ones that aren't in view, but they aren't being rendered anyway so why bother? Its just a waste of cpu cycles.

Plus storm troopers phasing in and out of existence, losing their health values, AI state, etc doesn't exactly enhance the experience for the player.

Now, if you used firstthinginview to turn rendering off (rather than deleting them like the RTVCS or whatever does) on distance objects (geomode zero) that might up framemrates some at a mild graphical cost, without causing inconsistant bullet hits....but JK already switches to crappy *** models on distance objects to up frame rate...and you can still see them so that you can shoot them! You'd have to add a fog effect to make it look halfway plausable. Again, it'd be a great idea for for forests (which opens much more potential up for)

I'd have to ask GBK since he wrote it, but my understanding of that TCS is that it exists to work around the thing limit and that it does not in fact do much if anything to increase framerates. Didn't GBK himself just pop in here and say it was now useless? It only would stop objects from being rendered...that the JK engine wasn't going to render anyway! Objects that you couldn't see. So my understanding is...you're just redoing a job that the JK engine already does a pretty good job of doing on its own.

And no one is saying "abandon good editing practices now people! The thing limit is removed, now add 500 stormies per sector for r0x0r levels!" But we COULD if we really wanted too. And if we wanted to build a huge *** level that had 5,000 stormies spread throughout it, we COULD do it. And if we wanted to make a very large RPG level, we CAN! This has stood in the way of the scope of many editors projects. Grand single player levels had to be reworked with architecture and sacrificing both framerate and editing time, the JKRPG was forced to limit scope in order to get under the mark.

And you say modern games on the shelves, a catagory which JK is not a member of, don't render more than 320 objects on the screen....I ask you, is that because they CAN'T, or because the designers of the levels see fit to prevent such things from happening through level design and item/enemy placement? And are you counting lights as part of those 320 objects? Because JK needs things for its dynamic lights as well you know...

There's still a place for the TCS, or some variation of it...but that place isn't in every level. And frankly, it never was.

My point was, that with the RVTCS you could run into 800 stormies in a single sector....if you wanted to.



Actually, you can have that information stored in the RVTCS...I'd discussed that with GBK already about a year ago. It was planned for v4.



The RVTCS has a built in LOD system. You can also use it for Large Indoor rooms....such as grand hallways, ballrooms, etc. Or you can use it for small rooms.



Is original TCS cog was indeed a work-around to the thing limit. It was incredibly sophisticated. Tracking health, AI, doors, and many other things. The RVTCS, however, was intended to be a 'primative' culling system for JK (see above posts). When used correctly, it can take objects from really high detail to really low detail and back again simply based on the distance to the player (locally...meaning it doesn't effect what's being rendered on someone elses machine).



That's all fine and dandy any all, but if you can keep the numbers down to less then about 600 objects existing at one time (excluding players, weapons, bullets, etc.), then why not save the end-user the extra download time of including the patch?



They don't do it due to Frame Rate. Which was the same point I've been trying to get accross. On my 2.8Ghz, GeForce5, w/ 1GB of DDR RAM, the last thing I should have to worry about while playing a JK game is Frame Rate... You do realize that the JK engine doesn't render objects half as effeciantly as games on the shelves right now do....right?



Here's where your dead wrong. To not use the RVTCS is rather foolish. It adds a dimension to the JK engine that simply doesn't exist otherwise. Any size level can use it. Now, this is not to say that you can't use this 'patch' and the RVTCS together. You can. But I wouldn't advise doing it unless you really did want more then 600 objects to exist within the viewing distance of the player at any given time. Though that wouldn't be good editing practice either...

Most levels are hundreds or thousands of times larger than the patch. The patch is quite miniscule actually. Even the smallest of levels are larger. So it's not a worry for download time.



What he's pointing out is, framerate is not really an issue, at least with things. You're more likely to lose framerate from level architecture and adjoins than you are from too many things.



If I'm in a large room, I'd expect to be able to see the things on the other side of that room. Secondly, it would require at least 4 seperate models and 4 templates to match JK's system, which handles it all within the same model, meaning only one template. Beyond that, you'd have to add four instances of the cog, and input the sperate data for each LOD.



No, this is where you're dead wrong. There's no reason to use it to get around the thing limit, when you can use a small patch to do so. (And that's what it's mainly been used for) I've personally never touched the RVTCS. No need to. And there's many, many other editors who could say the same. About the only use now is in large open outdoor levels where there's a risk of rendering 600 things at once. In general, RVTCS does add something... A lot of work. And in most cases, it's now unnecessary work, when you can simply insert the template and be done. For those large outdoor 3do-based levels, it's probably useful. However, 95% of cases, theres no need of it.

Damn, boys, better use your time for editing, than waste it in a pointless argue.

Blah, so much for anti-midnight lurking without posting.

I had to skim, I'm short on time. But why not just switch the geomodes of stuff when they're far away? (Or use the 3do LOD system to a point that compensates dramatically for each LOD, like, the lowest detailed would have 2 faces :p )

Yeah, isn't that patch, like, 5kb?
Heh, smaller than most level screenies too...

45.4kbs to be exact. About 15 more seconds for a level to download on 56k.

Anyone else notice while playing this this little demo level, that some of the stormtroopers appear to be brain dead? Its like they have no AI file or something.

Visual/auditory decision threshold?

Simple...use the patch to avoid the DVTVCR having to fetch, store, put, etc. dozens of data fields for hundreds of objects as often as every frame. Then write a simple frustum culling COG (CDTVTCS whatever)which flags things to invisible if they are outside of the player's 90 degree viewing frustum. This can be done locally with some vector math. Additionally cull things at whatever maximum viewing distance you want.

The result? As many things as you want rendered only when you can see them on your screen. They won't be rendered but they can still shoot at you. Either I missed something or Friend14 needs to stop protecting his RVTVCDTS brainchild like vultures are flying overhead.