Is it possible to create a material which have no default technique?
I would like to have a certain object only being rendered when a special technique is active. Is this possible or do I have to figure out another way to accomplish this?
Just let the default technique render nothing? As this happens at shader level and the java part is basically oblivious of whats happening I guess its hard to get it to cull or something at that level already.
Do you mean like having a NOOP shader or just leaving the Default block empty?
Leaving the block empty crashes with “java.lang.IllegalStateException: Cannot render mesh without shader bound” so that did not work" which makes sense I guess.
the default technique is the fist one declared in the j3md, so there is no way around it.
The empty shader could work but you’ll still send the mesh data to the GPU and still have a draw call…
What do you want to do? I mean a bigger picture…
The bigger picture is that I’m thinking about the deferred shading stuff again, and it makes my brain hurt 
(My thinking hat is probably to small).
Yeah, I know that the NOOP shader would issue useless draw calls… which is a deal breaker, so I’m moving on another idea.
Next question:
Is it a bad idea to create a viewport which is no handled by the renderManager? (Not added to the pre/main/post viewport lists).
@kwando said:
The bigger picture is that I'm thinking about the deferred shading stuff again
Yeah ok...maybe a bit smaller picture :p
What do you want to render alone? what is the scenario?
@kwando said:
Is it a bad idea to create a viewport which is no handled by the renderManager? (Not added to the pre/main/post viewport lists).
You can...technically, but you'll have to handle everything by yourself...update loop, render loop and so on.
Also i don't see the point in not adding it.
@nehon said:
Yeah ok...maybe a bit smaller picture :p
What do you want to render alone? what is the scenario?
My idea was to add the light bounding volumes to the main scene graph, with a material that has no default technique and thus will not be rendered when doing forward rendering. I have already scrapped that idea since I really do not want to have it in the same graph :P
Using a viewport that is not registered to the renderManager have reduced the complexity of my code big time. There is actually hope that this all can be made into a single scene processor which will play nicely with the other ones :) But I have to find a pesky error which is somewhere inside a shader written to long time ago -.- then I can claim this approach valid :P
@nehon said:
Also i don’t see the point in not adding it.
I want to nest viewport rendering within a scene processor, but that is not really possible with pre/main/post viewports.
@kwando said:
My idea was to add the light bounding volumes to the main scene graph, with a material that has no default technique and thus will not be rendered when doing forward rendering. I have already scrapped that idea since I really do not want to have it in the same graph :P
in/post viewports.
It's almost like you want some kind of separate Bucket to stick them in so that they get Rendered differently or something... ;)
@pspeed, I feel like your are trying to the tell me something (or somebody else) something, but I don’t get it 
I have been thinking a lot about the bucket system, and I would really like to see an overhaul in that area… right now you can’t have custom buckets unless you are willing to edit the core files since the types and their rendering is hardcoded into the RenderManager and RenderQueue
The renderManager class which is huge and have a lot of responsibility, maybe it should be split to smaller pieces. I tend to get confused when reading through that code, there is a lot of calls between Viewport, RenderQueue, Renderer and RenderManager involved in the process of rendering a viewport… maybe this could be straightened out somehow.
@kwando said:
@pspeed, I feel like your are trying to the tell me something (or somebody else) something, but I don't get it :P
I have been thinking a lot about the bucket system, and I would really like to see an overhaul in that area... right now you can't have custom buckets unless you are willing to edit the core files since the types and their rendering is hardcoded into the RenderManager and RenderQueue
The renderManager class which is _huge_ and have a lot of responsibility, maybe it should be split to smaller pieces. I tend to get confused when reading through that code, there is a lot of calls between Viewport, RenderQueue, Renderer and RenderManager involved in the process of rendering a viewport.. maybe this could be straightened out somehow.
Yeah, I was trying to be funny by insinuating that your use case is pretty much exactly what buckets are for. I didn't think you were trying to do this without modifying the engine.
I'm also not happy with the current bucket system and wish there could be custom buckets. I never have a good enough use-case handy for when I'm trying to argue for it though. However, any time you have half a dozen methods all with a switch-case EnumValue block in them then something is wrong.
@pspeed, I’m trying to avoid changing things in the core until I really have to… I know myself, and once I start to change things I’m not gonna stop until I’ve rebuilt the entire engine -.- Of course I could just add one extra bucket but as you mentioned, it’s hurting my programmer pride to add another enum and a new case clause
How the shadowing is done is one argument I think. Right know geometries is sorted into the shadow buckets regardless if the viewport has a ShadowProcessor/filter or not. I think the shadowprocessor should register the buckets it needs to be filled for instance.
I already argued with Kirill about custom bucket to no avail. As Paul, even if I feel it would be better, i have no real use case to expose.
About the renderManager, there is an issue in the tracker to split it.
@kwando said:
How the shadowing is done is one argument I think. Right know geometries is sorted into the shadow buckets regardless if the viewport has a ShadowProcessor/filter or not. I think the shadowprocessor should register the buckets it needs to be filled for instance.
Actually the shadow buckets are not really buckets per se because the render manager does not handle their rendering. The processor does.
Actually it's just geometry lists really, and they are built considering the shadow cast/receive hint set on the spatials (defaulted to false).
So they are built only if you set the shadow hint to something else than "Off".
Calling them bucket is just a bit abusive, because bucket are only supposed to speed up the sorting process to define the rendering order.
Maybe your solution of having another viewport is the good one. Especially if you want an off screen texture of the render of this viewport.