PDA

View Full Version : Mesh effects in cab view



norfolksouthern37
June 16th, 2015, 01:36 PM
In all previous releases of Trainz mesh table effects including meshes that were attached at a.cabfront were not culled when moving to cab view; only the main objects in the mesh table were removed. I realize this may have been a very long standing bug, but it had some very good uses and seemed to be intentional since it only worked if attaching an effect to a.cabfront. For instance, I often used this to attach windscreen wipers to the body of a locomotive yet still have them remain visible when in the cab view. This of course simplified script code and removed the need for many duplicate parts in that the object could be animated and viewed inside or outside the cab. In TANE these effects objects no longer show as they are culled with the main object when entering the cab.

The question here is, is there any possibility of having this re-implemented? If not, is the answer simply to update all objects and use multiple references to the same attach item and more script code for a TANE only version?

WindWalkr
June 16th, 2015, 06:22 PM
The old behaviour is most definitely an implementation artefact and not something you should be relying on. If this is causing substantial problems then we may look at some kind of compatibility shim in the future, but I can't give a timeline on when this might happen and we'd probably address it by only enabling the shim for older content.

For future content, you should (1) not attach anything except the cab to the cab's attachment point, and (2) assume that anything outside the cab is invisible while in cab view unless the outside-visible-from-cabin flag is enabled. This flag is not really intended for train car interiors, and is likely to cause some unexpected visual effects if used in that scenario.

chris

norfolksouthern37
June 16th, 2015, 09:30 PM
The old behaviour is most definitely an implementation artefact and not something you should be relying on. If this is causing substantial problems then we may look at some kind of compatibility shim in the future, but I can't give a timeline on when this might happen and we'd probably address it by only enabling the shim for older content.

It was a sensible 'artifact' if it was anything as it provided a way to keep an object visible in both views before we could enforce only an entire asset to remain visible. When the 'outside-visible-from-cabin' tag is impractical, which is 95% of the time when making train vehicles something much smaller is preferable. Think about it before you just write off what I said and throw it away in the N3V 'stuff we dont care about because we know exactly how it needs to work' bin because I already have plenty in there. I appreciate you coming on here to read the posts but I feel like you immediately brushed it off without even reading it. You certainly didn't answer anything I asked.

I never really said that I would be relying on it, just that I had before and I thought the effect attachment to a.cabfront made a lot of sense. I would like for this to be possible again unless you know some really good reason that it shouldn't. I will have to make several changes to existing content - even quite a few DLC items to correct the problem in TANE.


For future content, you should (1) not attach anything except the cab to the cab's attachment point, and

Explain - WHY should this be done? That really doesn't make a lot of sense.


(2) assume that anything outside the cab is invisible while in cab view unless the outside-visible-from-cabin flag is enabled. This flag is not really intended for train car interiors, and is likely to cause some unexpected visual effects if used in that scenario.

k

WindWalkr
June 28th, 2015, 08:49 PM
Think about it before you just write off what I said and throw it away in the N3V 'stuff we dont care about because we know exactly how it needs to work' bin because I already have plenty in there. I appreciate you coming on here to read the posts but I feel like you immediately brushed it off without even reading it.

The point is that you're talking about something that we don't support, and it's not working reliably for you because it's something that we don't support. If you want to put a vote in for getting a supported way of doing something, that's fine, but asking questions about why something doesn't work when we don't support it is going to be a bit fruitless- the answer is simply that we don't support that and thus the behaviour is undefined.



Explain - WHY should this be done? That really doesn't make a lot of sense.

The sole purpose for these attachment points is so that the interior can be attached there. We manipulate them in various ways internally based on the needs of our interior-rendering code. This changes as our internal requirements change. It's not intended that you reuse them as general-purpose attachment points, and if you do, then you will become subject to whatever changes occur in our internal rendering code which will certainly not be written to take your external functionality into account.

I guess if we were to rebuild this system now, we'd probably separate "user-defined attachment points" out as a subclass of normal attachment points (eg. "a.blah" for internal and "a.u.blah" for third-party or whatever) but that ship has long since sailed.

chris

norfolksouthern37
June 28th, 2015, 09:51 PM
You missed the question then. I didn't ask why it doesn't work.


The question here is: is there any possibility of having this re-implemented? If not, is the answer simply to update all objects and use multiple references to the same attached item and more script code for a TANE only version?

I don't understand why you can't just answer that.

As for the rest, the intention was to use the point as attachment for interior items - just as you stated it should be. It should not matter if it is one interior mesh or several that form a whole.

Since you can't seem to get the question I asked in the original post the question should probably be if there is some way we can get a way to attach items for both exterior and interior so that you don't have to reference the same item twice in the same location. I can't imagine that attaching some item multiple times for interior and exterior makes sense resource-wise. The exterior is destroyed when you enter cab view; this is understandable, but if I need the same item in both places unloading it and re-loading it doesn't really make a lot of sense. The pre-TANE way allowed this sensible behavior regardless if you support it or not.

WindWalkr
June 29th, 2015, 02:07 AM
The question here is: is there any possibility of having this re-implemented?

No; as above, it's never been intended to work reliably this way and never will be. Also as above, if you need some specific functionality, then I'm happy to talk about alternative approaches, but it's not going to be based around overriding the default attachment point behaviour.

For example, one approach might be to add a new variant of the "outside-visible-from-cabin" tag which allows us to tag specific sub-meshes which will remain visible, rather than it being an all-or-nothing affair. We could perhaps tag this in the mesh-table rather than at the top level.



If not, is the answer simply to update all objects and use multiple references to the same attached item and more script code for a TANE only version?

You're right, I missed this part. I might need some more information on what you're trying to do. There's no problem having a single IM file referenced from both the exterior and interior views, but it sounds like you're trying to take things further than this? From the reference to wipers, can I assume that you're talking about having script-animated or otherwise script-modified objects which are visible from both views? Is there a guarantee that these objects are physically outside the cabin, or are some of them inside the cabin as well? Anything else that you can give as context would be useful.



..the question should probably be if there is some way we can get a way to attach items for both exterior and interior so that you don't have to reference the same item twice in the same location. I can't imagine that attaching some item multiple times for interior and exterior makes sense resource-wise. The exterior is destroyed when you enter cab view; this is understandable, but if I need the same item in both places unloading it and re-loading it doesn't really make a lot of sense. The pre-TANE way allowed this sensible behavior regardless if you support it or not.

My only real concern here is that we handle things a bit differently depending on whether they're considered as part of the cab view or part of the exterior. The exact differences have changed over time depending on our requirements; this can include things like being rendered with a different z-buffer range, rendering with different lighting parameters, disabling LOD, substituting materials, and disabling shadowing effects to avoid distortions which can naturally occur when ultra-small objects are very close to the observer, and so on. I can't give you a definitive list as this is the kind of thing we need to leave open to allow us to adjust for future changes. As the capabilities of the underlying hardware and renderer technology change, so do the differences in how we treat special cases like the cab interior.


chris

norfolksouthern37
June 29th, 2015, 08:52 AM
No; as above, it's never been intended to work reliably this way and never will be. Also as above, if you need some specific functionality, then I'm happy to talk about alternative approaches, but it's not going to be based around overriding the default attachment point behaviour.

I didn't try to tell you how to do it that isn't my concern, and as far as I knew I was using default attachment behavior. Thank you for finally answering.


For example, one approach might be to add a new variant of the "outside-visible-from-cabin" tag which allows us to tag specific sub-meshes which will remain visible, rather than it being an all-or-nothing affair. We could perhaps tag this in the mesh-table rather than at the top level.

This would work for me and is what I've been trying to convey the entire time.



You're right, I missed this part. I might need some more information on what you're trying to do. There's no problem having a single IM file referenced from both the exterior and interior views, but it sounds like you're trying to take things further than this? From the reference to wipers, can I assume that you're talking about having script-animated or otherwise script-modified objects which are visible from both views? Is there a guarantee that these objects are physically outside the cabin, or are some of them inside the cabin as well? Anything else that you can give as context would be useful.


If I am writing too much text for you to read in one sitting just let me know and we can find a more acceptable way of communicating. I am only trying to help here as requested by Paul - This is one of the things that causes an immediate issue with content. If you guys want to change the way things have always worked and break stuff that is up to you.

Here is the only information on what I have done for years under every Jet version:

attach animated windscreen wipers as mesh effects to the a.cabfront in the main asset mesh table.
because they are attached here they remain visible when in cabin (only worked with mesh effects).
get a reference to the attached effects from the cabin script and apply toggles for the animation, this also works in or out of the cab since it is the same object.

There is really nothing more to it than that.

I realized (as i said in the first post) that this was probably an oversight by one of you and was not really intended to function this way but it worked beautifully. I attempted to highlight the pros to this method by pointing out that the assets (the wipers) only had to be referenced once by the exterior mesh asset - they dont have to be destroyed and loaded again by the interior nor is there any need for scripting (multiple calls to StartMeshAnimationLoop("default"); for both assets to toggle the animation).

I will have to just assume your answer to my question is yes and that this feature will never come back and I need to do double the work, make the code do double the work, and use double the resources for TANE.



My only real concern here is that we handle things a bit differently depending on whether they're considered as part of the cab view or part of the exterior. The exact differences have changed over time depending on our requirements; this can include things like being rendered with a different z-buffer range, rendering with different lighting parameters, disabling LOD, substituting materials, and disabling shadowing effects to avoid distortions which can naturally occur when ultra-small objects are very close to the observer, and so on. I can't give you a definitive list as this is the kind of thing we need to leave open to allow us to adjust for future changes. As the capabilities of the underlying hardware and renderer technology change, so do the differences in how we treat special cases like the cab interior.


Doesn't sound like anything I care about but you guys do need to learn how to make those shadows work without taxing the hardware, there are some great docs on it but that is another topic.

WindWalkr
June 29th, 2015, 08:12 PM
I will have to just assume your answer to my question is yes and that this feature will never come back and I need to do double the work, make the code do double the work, and use double the resources for TANE.

It has drawbacks for us, as the two paths (interior and exterior) are supposed to do different things. Circumventing this and forcing them to do a single thing does marginally reduce the work that the engine has to do, but it also means that the deliberate changes we make don't get applied and that can be problematic. Exactly how problematic this is depends on the content (which you have control of) and the internals of the build (which you don't.)

I'll pencil in a task to look into ways to officially support what you're looking for, but it won't come in the timeframe of the current product.

cheers,

chris

WindWalkr
September 18th, 2015, 06:45 AM
If this is causing substantial problems then we may look at some kind of compatibility shim in the future, but I can't give a timeline on when this might happen and we'd probably address it by only enabling the shim for older content.

This shim is now in place for the latest test version. Please let me know if you think it's not working properly for any of your existing content.



I'll pencil in a task to look into ways to officially support what you're looking for, but it won't come in the timeframe of the current product.

This is still in the queue.

chris