transient,
I mean any kind of invisibility which would possibly achieve the desired end result.
In essence what I meant was segment walls which can be painted as normal room segments, but which are transparent.
God,
I do not refer to dynamic entities at all - thats not whats needed. What is needed are normal segment walls/floors/ceilings which do not render as visible, but nevertheless in theory at least block the view as far as the engine is concerned so that the view and therefore poly counts in that view are restricted - thats the whole point. The question is can such be acieved in this or any other way.
Put simply :
If you have a level constructed and place somewhere say for example in the middle of the level a single room comprising walls/floor and ceiling and place the player inside that closed 1 cubic tile room, presumably in theory at least poly counts and fps should be what one would describe as reasonable and acceptable as there should no way there is going to be anything much in view from any point inside that room. It would be reasonable to expect that the engine should not be able to see or draw (in terms of world objects(walls) ) in its calculations anything outside of that room as neither the player/camera, nor the egnine should be able to see through the walls.
Now presuming that is correct my question is this :
If I do the same placing the player in a room ideally constructed from a room segment but using 100% transparency applied to the textures so that ( visually only ) the room eclosing the player is now invisible -
"Does the engine also see the room walls/fllor/ceiling as being invisible and non existant - removing it from visibility calculations and thus seeing everything in the view outside of the room" or
even though transparent
"Will the engine still see the room as solid and existant and discout the world object construction outside of the room and discount the same in its poly counts" thus returning the same result as the first example?
You can see the obvious possible benefits if this is so. Although adding content in theory if you could restrict the view in this manner using invisible rooms then you could effectively divide up a level by region or segmented areas thus limiting poly counts and fps breaking the level down to managable segmented areas whilst seemingly having a single unbroken level. Similar methods of division of levels is and has been used successully in other engines where invisible area breakers or dividers which the engine cannot see through are placed to seperate a large level and restrict poly counts into manageable zones or areas - the question is can it be done in FPSC?
Of course this will not correct the lagg issue in FPSC where it calculates unaccountable excessive poly counts in specific small areas as it wont fix the problem or bug whatever it is - but its a method I was thinking might work to overcome or workaround the problem and thus find a forced fix. Indeed if it could be done then it could achieve a fix albeit by a litlle cheating and could possibly be used to generate stable fps throughout a level.
On the other hand it may not fix the lagg problem at all as FPSC may still come up with erratic calculations and see specific tile locations as returning excessive poly counts irerespective. If its calculation methods are flawed and unstable anyway nothing can in any certainty be relied upon to work.
Only one way to answer this question and that is I will attempt some experimentation when I get some time - though any help or suggestions would be obviously most welcome.
