Ma-Shell

Are you using some fancy new technology like MVR or one of its predecessors for the single pass point-lights? If so, have you also evaluated, what happens on older GPUs?

There is but that isn't trivial to implement: Basically you create a grid where each cell lists all the enemies within the region. This requires that when an enemy changes position, it also removes itself from the old cell's list and inserts itself into the new one. Then the player only has to search through the lists of the nearby cells. Of course the additional bookkeeping might have a different performance impact but especially, if the entities also sometimes react to one another or if you're checking the distance more often, this will certainly pay off.

What does the code for differently coloured letters look like? Do you call CreateText once for every letter and then position them manually or is there a nicer way?

Is it possible to combine more than 2 worlds (possibly by daisy chaining them)?

I see two possible issues with filters: 1. I understand a filter as having some sort of "layer-id" on the objects and a camera only rendering objects with a given layer-id. Suppose, you have two objects A and B. If you want to first render A and B and then from a different camera only B (e.g. you have a vampire in front of a mirror. You would want the entire scenery to include the vampire but when rendering the mirror, you would want to render the scenery from that perspective without the vampire). This would not be easily possible with a layer-id. 2. Performance: You have to run through all objects and see, whether they match the filter in order to decide, whether to cull them or not. If you instead just walk the world's list of entities, this does not happen. Why not using something like this: camWorldA->SetClearMode(ColorBit | DepthBufferBit); camWorldB->SetClearMode(DepthBufferBit); camWorldC->SetClearMode(DepthBufferBit); context->ClearWorlds(); // nothing is being rendered context->AddWorld(worldA); // All cameras of world A are rendered context->AddWorld(worldB); // First all cameras of world A are rendered, then all of world B context->AddWorld(worldC); // First all cameras of world A are rendered, then all of world B, then all of world C This would give the user maximum flexibility and only require the context to hold a list of worlds, which are rendered one after another instead of having a single active world. For compatibility and comfortability reasons, you could additionally define void World::Render(Context* ctx) { ctx->ClearWorlds(); ctx->AddWorld(this); } This way, you could still use the system as before without ever knowing of being able to render multiple worlds. EDIT: I see, my vampire wouldn't work with this system, as well (unless you allow a mesh to be in multiple worlds) but I still think, this is quite a flexible and easy to use system without much of an overhead

Isn't that basically what a world is? Each camera renders only the objects that are in its world, so the world is basically a filter for the camera

Ah, I see... So the rendering always uses the last world, which called World::Render() and uses all cameras from that world in the specified order? Would it be possible to implement the same ordering as with cameras for worlds then? Like the following realWorld->setOrder(1); HUDWorld->setOrder(2); where it would first render all cameras from realWorld and after that all cameras from HUDWorld. This would probably mean, it is more intuitive to have the render-call on the context instead of the world, since all worlds would be rendered. By the way, is there any way to disable certain cameras, so they get skipped? Like setting a negative order or something like this. What happens if you set two cameras to the same order?

You mean, because unlike the previous version the user does not directly call Render() anymore, since it is run on a different thread and thus the user can not correctly orchestrate the rendering? This should not be a problem, since in CreateCamera you can specify the world. auto realCamera = CreateCamera(realWorld); auto HUDCamera = CreateCamera(HUDWorld); realCamera->setOrder(1); HUDCamera->setOrder(2); realCamera->SetClearMode(CLEAR_DEPTH | CLEAR_COLOR); HUDCamera->SetClearMode(CLEAR_DEPTH);

Would it be possible to use two different worlds for this? One "real" world and one for your HUD and then first rendering only the first world and after that rendering the HUD-world.

The model probably does not have a surface. You should get the number of surfaces first and then iterate over the surfaces. Something like the following (I don't know much about lua, so probably this code won't work without modification): for k,v in pairs (self.modelTable) do for i = 0, v:CountSurfaces(), 1 do surface = v:GetSurface(i) mat = surface:GetMaterial() mat:SetShader(shader) shader:SetVec4("ex_color",self.color) mat:SetColor(self.color) self.modelTable[k] = nil end end

As I said, you should take a look at the objects on your map and the scripts they have attached!

I am pretty sure, the problem is coming from a LUA script of an object in your map, not from C++. That script has probably a world render or update hook, where it tries to access that variable.

No, the comment "//lua" only means that this function is available in lua, as well, but that does not mean, that it is only executed in lua. As for your other problem, it seems like you might not be setting the variable "world" before calling the Update-function or you are probably setting a function-local variable in the Start-function and then accessing a global variable in the update function or something like that. It's hard to say without seeing your code.

Also, looking at https://www.gamedev.net/forums/topic/673534-instancing-and-the-various-ways-to-supply-per-instance-data/?do=findComment&comment=5264179, you can create the buffer much larger first, then copy all data and later repeatedly use glBindBufferRange instead of glBufferSubData, copying all data in one go and being much faster

ah, I see, so you're refering to GL_MAX_UNIFORM_BLOCK_SIZE (https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glGet.xhtml)? I think, it would make sense, to query that number in the beginning and use that instead of the fixed 256. Otherwise every system would suffer, only so that it can run on lower end systems. EDIT: Of course I mean use that number divided by 64