DX9 FF to Vulkan

[sbrkopac]

Hi All,

I'm in the process of trying to upgrade a codebase from DX9 into Vulkan. My base level of understanding is very minimal so please bear with me.

The original code base has the following Mesh class (trimmed):

class Mesh
{
public:
    ...

    int Render( int flag, const NodeTexColl& texList, DWORD* litColorArray, const DWORD alpha ) const;

    ...
};

This does what you'd expect:

• Fill alpha if required
• SetTextureStages
• SetRenderState
• Render

I've managed to get a minimal example setup from the code base and am generating a structure as follows (some variables unused so far):

RapiStaticObject::RapiStaticObject(
	sVertex* pVertices,								// Vertex info
	int numVertices, int numTriangles,				// Number info
	TexStageList& stageList,                        // Stage info	
	std::vector< gpstring >& tempTextStringsForVulkan)	// temporary for vulkan rendering					
	: m_numVertices(numVertices)
	, m_numTriangles(numTriangles)
	, m_pVertices(pVertices)
	, m_TexStageList(stageList)
{

	// Build up a default texture list
	StaticObjectTex tex;
	tex.textureId = 0;
	tex.alpha = false;
	m_texlist.resize(m_TexStageList.size(), tex);

	auto vertices = vsg::vec3Array::create(numVertices);
	auto normals = vsg::vec3Array::create(numVertices);
	auto colors = vsg::vec4Array::create(numVertices);
	auto tcoords = vsg::vec2Array::create(numVertices);

	m_pBindVertexBuffers = vsg::BindVertexBuffers::create(0, vsg::DataList{ vertices, colors, tcoords });
	addChild(m_pBindVertexBuffers);

	for (int i = 0; i < numVertices; i++)
	{
		vertices->at(i) = vsg::vec3(pVertices[i].x, pVertices[i].y, pVertices[i].z);
		tcoords->at(i) = vsg::vec2(pVertices[i].uv.u, pVertices[i].uv.v);
	}

	for (auto& stage : m_TexStageList)
	{
		// texture setup
		auto textureName = tempTextStringsForVulkan[stage.tIndex];
		auto textureData = readTextureAndReturnData(textureName).cast<vsg::Data>();

		auto layout = ehb::SiegeNodePipeline::instance().PipelineLayout;
		auto texture = vsg::DescriptorImage::create(vsg::Sampler::create(), textureData, 0, 0, VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER);
		auto descriptorSet = vsg::DescriptorSet::create(layout->setLayouts[0], vsg::Descriptors{ texture });
		m_pBindDescriptorSets = vsg::BindDescriptorSets::create(VK_PIPELINE_BIND_POINT_GRAPHICS, layout, 0, vsg::DescriptorSets{ descriptorSet });

		addChild(m_pBindDescriptorSets);

		auto indices = vsg::ushortArray::create(stage.numVIndices);
		for (int i = 0; i < stage.numVIndices; i++)
		{
			indices->at(i) = stage.pVIndices[i];
		}

		m_pBindIndexBuffer = vsg::BindIndexBuffer::create(indices);
		m_pDrawIndexed = vsg::DrawIndexed::create(stage.numVIndices, 1, 0, stage.startIndex, 0);

		addChild(m_pBindIndexBuffer);
		addChild(m_pDrawIndexed);
	}
}

Then in my application I do the basic of setting up the pipeline and then the following:

auto scenegraph = vsg::StateGroup::create();
scenegraph->add(ehb::SiegeNodePipeline::instance().BindGraphicsPipeline);

auto transform = vsg::MatrixTransform::create();

auto m3 = mesh.GetRenderObject();
transform->addChild(m3);

scenegraph->addChild(transform);

The above works when setting up a default graph of the meshes that I want. Now I'm looking into how to best get the old API to work with the Frustum class. Based on my research I'm leaning toward a subcommand graph approach. Similar to this: https://github.com/kondrak/quake_bsp_vulkan/blob/bb149b8f15ee02417c183f9421ce8c5aae06f7fc/src/q3bsp/Q3BspMap.cpp#L538

My understanding is that I can setup that secondary command graph every frame and in the Frustum class, if something is visible - add it to the graph. Looking for feedback if I'm on the right track here. The new function would look something like:

int Render( int flag, vsg::ref_ptr<vsg::Commands> commands);

Then in the Frustum if a node is visible, I'd record into the corresponding secondary graph and bob is your uncle. Am I overcomplicating the approach? Am I able to simplify this and just rebuild an entire vsg::Group and swap it out on each update? Any advice would be appreciated.

Thanks!

edit: For clarity, I'm not just talking about view culling. I'd like to replace all those Draw calls so I can get a working scene that is adapted to the original Draw call.

[robertosfield]

The VSG already has view frustum culling, all you would need to do is decorate subgraphs with a CullNode/CullGroup/LOD/PagedLOD or implement your own cull node. I wouldn't recommend adding/removing elements of the scene graph on the fly, if you really wanted to do this type of dynamic adding/removing then a custom node with it's own traverse method might be best to walk through the subgraphs to call.

I would generally recommend keeping things simple though, the scene graph will probably perform well enough with just using the standard components like the above mentioned culll nodes.

[sbrkopac]

I completely understand where you're coming from. That does 100% take care of my view culling. What I'm driving at here is trying to keep the API intact for all drawing in the application. For instance there is debug data against pieces of the terrain to draw bounding boxes, trees, and other data. I'd like to try to get a compatibility layer in to see those things drawing.

My thought was if I could adapt that draw function as a secondary command graph I'll be able to obtain drawing and then begin to rebuild those pieces with a working scene for reference.

[robertosfield]

It may be possible to write a custom node that overrides the Object:accept(RecordTraversal&) method and then traverses all the internal data structures that your application has, so rather than addChild/removeChild() you just directly traverse the data structures and call the vsg::Node's accept on the VSG components you associate with them.

These VSG components could be invoking the recording of use of secondary command buffers but this would be a later optimization if required.

Given you a porting old software I would expect that the CPU and GPU load will be low enough that optimization needn't be your first priority - just getting something working should be.

[sbrkopac]

That should work. Off the top of my head I'll have to be careful of making sure the objects get compiled before that RecordTraversal is called since I won't be using addChild in the Custom Node.

[sbrkopac]

Looks like inheriting from vsg::Compilable makes it kinda clean in vsgdraw

class CustomDrawNode : public vsg::Inherit<vsg::Compilable, CustomDrawNode>
{
public:
    CustomDrawNode()
    {
        // set up vertex and index arrays
        auto vertices = vsg::vec3Array::create(
            {{-0.5f, -0.5f, 0.0f},
             {0.5f, -0.5f, 0.0f},
             {0.5f, 0.5f, 0.0f},
             {-0.5f, 0.5f, 0.0f},
             {-0.5f, -0.5f, -0.5f},
             {0.5f, -0.5f, -0.5f},
             {0.5f, 0.5f, -0.5f},
             {-0.5f, 0.5f, -0.5f}}); // VK_FORMAT_R32G32B32_SFLOAT, VK_VERTEX_INPUT_RATE_INSTANCE, VK_BUFFER_USAGE_VERTEX_BUFFER_BIT, VK_SHARING_MODE_EXCLUSIVE

        auto colors = vsg::vec3Array::create(
            {
                {1.0f, 0.0f, 0.0f},
                {0.0f, 1.0f, 0.0f},
                {0.0f, 0.0f, 1.0f},
                {1.0f, 1.0f, 1.0f},
                {1.0f, 0.0f, 0.0f},
                {0.0f, 1.0f, 0.0f},
                {0.0f, 0.0f, 1.0f},
                {1.0f, 1.0f, 1.0f},
            }); // VK_FORMAT_R32G32B32_SFLOAT, VK_VERTEX_INPUT_RATE_VERTEX, VK_BUFFER_USAGE_VERTEX_BUFFER_BIT, VK_SHARING_MODE_EXCLUSIVE

        auto texcoords = vsg::vec2Array::create(
            {{0.0f, 0.0f},
             {1.0f, 0.0f},
             {1.0f, 1.0f},
             {0.0f, 1.0f},
             {0.0f, 0.0f},
             {1.0f, 0.0f},
             {1.0f, 1.0f},
             {0.0f, 1.0f}}); // VK_FORMAT_R32G32_SFLOAT, VK_VERTEX_INPUT_RATE_VERTEX, VK_BUFFER_USAGE_VERTEX_BUFFER_BIT, VK_SHARING_MODE_EXCLUSIVE

        auto indices = vsg::ushortArray::create(
            {0, 1, 2,
             2, 3, 0,
             4, 5, 6,
             6, 7, 4}); // VK_BUFFER_USAGE_INDEX_BUFFER_BIT, VK_SHARING_MODE_EXCLUSIVE

        m_pBindVertexBuffers = vsg::BindVertexBuffers::create(0, vsg::DataList{vertices, colors, texcoords});
        m_pBindIndexBuffer = vsg::BindIndexBuffer::create(indices);
        m_pDrawIndexed = vsg::DrawIndexed::create(12, 1, 0, 0, 0);
    }

    void compile(vsg::Context& context) override
    {
        std::cout << "CustomTestNode::compile(vsg::Context& context)" << std::endl;

        m_pBindVertexBuffers->compile(context);
        m_pBindIndexBuffer->compile(context);
        m_pDrawIndexed->compile(context);
    }

    void accept(vsg::RecordTraversal& recordTraversal) const override
    {
        std::cout << "CustomTestNode::accept(vsg::RecordTraversal& recordTraversal)" << std::endl;

        m_pBindVertexBuffers->accept(recordTraversal);
        m_pBindIndexBuffer->accept(recordTraversal);
        m_pDrawIndexed->accept(recordTraversal);
    }

private:

    vsg::ref_ptr<vsg::BindVertexBuffers> m_pBindVertexBuffers;
    vsg::ref_ptr<vsg::BindIndexBuffer> m_pBindIndexBuffer;
    vsg::ref_ptr<vsg::DrawIndexed> m_pDrawIndexed;
};

[robertosfield]

It's more efficient to use vsg::VertexIndexDraw for this type of usage rather than using a custom node like above, it has lower CPU overhead and is cleaner.

A general comment, as much as possible you want to just compile the scene graph as little as possible - ideally just once at start up and then only if you have new resources that need compiling. The compile might actually do compilation like GLSL -> SPIRV but mostly it's creating Vulkan objects, allocating memory and then transferring memory to the GPU. What may be possible for you application type is allocate all the main Vulkan objects (include graphics pipelines/descriptor sets, descriptors and arrays at start up then just update the data that changes on the fly.

At start up you'd create more memory and objects than you need for the first frame, but create a pool that you manage the resources from. Then as new data comes in to be rendered you assign arrays from this pool and transfer the data required without needing to allocate/delete any resources.

This approach will be more complicated than standard scene graph usage but might make sense for porting a old era game that works in a particular way.