Render Path Grid v2

Involved development of the OpenMW construction set.
aesylwinn
Posts: 211
Joined: 14 Dec 2015, 20:30

Render Path Grid v2

Post by aesylwinn » 08 Apr 2016, 20:44

I plan on having a basic shape (probably a sphere) for nodes, and lines of 2 different colors (representing to/from) connecting different nodes. I was thinking of changing the color of a node based on how congested a single node is, though I don't really know if that would be helpful or not. Any thoughts on this feature?

User avatar
scrawl
Posts: 2047
Joined: 18 Feb 2012, 11:51
Contact:

Re: Render Path Grid v2

Post by scrawl » 08 Apr 2016, 21:01

Why not use reuse the shapes used in the OpenMW pathgrid renderer?

aesylwinn
Posts: 211
Joined: 14 Dec 2015, 20:30

Re: Render Path Grid v2

Post by aesylwinn » 08 Apr 2016, 21:35

Initially from ignorance. After looking at it, I think it would be easier to make the connecting lines start/end on a sphere. I also think it would look better, though that's my personal preference. :lol: If consistency is a concern, then perhaps I could post some pictures so people could judge which one to use.

If it's too much trouble, I can just use a diamond. Diamonds are forever after all...

User avatar
Zini
Posts: 5117
Joined: 06 Aug 2011, 15:16

Re: Render Path Grid v2

Post by Zini » 09 Apr 2016, 09:14

Consistency between OpenMW and OpenMW-CS is preferable.

Edges are not directional, so the two colour idea will probably not work.

aesylwinn
Posts: 211
Joined: 14 Dec 2015, 20:30

Re: Render Path Grid v2

Post by aesylwinn » 09 Apr 2016, 18:53

With the edges, there is a from/to in the form of "Point 0"/"Point 1" in the edge list for the editor. As I looked through the list, I noticed that both directions appear to be defined. I assumed this was relevant and that there was the option to make single direction paths. I'll take a look at the implementation to see if it is relevant.

aesylwinn
Posts: 211
Joined: 14 Dec 2015, 20:30

Re: Render Path Grid v2

Post by aesylwinn » 09 Apr 2016, 20:15

Code: Select all

ConnectedPoint neighbour;
neighbour.cost = costAStar(mPathgrid->mPoints[mPathgrid->mEdges[i].mV0],
    mPathgrid->mPoints[mPathgrid->mEdges[i].mV1]);
// forward path of the edge
neighbour.index = mPathgrid->mEdges[i].mV1;
mGraph[mPathgrid->mEdges[i].mV0].edges.push_back(neighbour);
// reverse path of the edge
// NOTE: These are redundant, ESM already contains the required reverse paths
//neighbour.index = mPathgrid->mEdges[i].mV0;
//mGraph[mPathgrid->mEdges[i].mV1].edges.push_back(neighbour);

Code: Select all

// check that edges are bidirectional
bool foundReverse = false;
for (unsigned int j = 0; j < pointList[i].mOtherIndex.size(); ++j)
{
    for (unsigned int k = 0; k < pointList[pointList[i].mOtherIndex[j]].mOtherIndex.size(); ++k)
    {
        if (pointList[pointList[i].mOtherIndex[j]].mOtherIndex[k] == static_cast<int>(i))
        {
            foundReverse = true;
            break;
        }
    }

    if (!foundReverse)
    {
        std::ostringstream ss;
        ss << " has a missing edge between points " << i << " and " << pointList[i].mOtherIndex[j];
        messages.add (id, pathgrid.mId + ss.str(), "", CSMDoc::Message::Severity_Error);
    }
}
It seems that the direction of the paths are taken into account, and that not being bidirectional is considered an error.

aesylwinn
Posts: 211
Joined: 14 Dec 2015, 20:30

Re: Render Path Grid v2

Post by aesylwinn » 19 Apr 2016, 15:58

Bit of an update. School has been a bit of a pain lately. :lol: I know how I'm going to implement this, but I haven't had the time to actually code it. I'll probably be able to get to it later this week.

aesylwinn
Posts: 211
Joined: 14 Dec 2015, 20:30

Re: Render Path Grid v2

Post by aesylwinn » 29 Apr 2016, 05:53

I just finished my last final so I now have some time to work on this. :) As I was working on implementing the visual updating code (from changes in data tables), I saw there were not any slots/signals that get triggered from the NestedColumnAdapter class. Is there some other mechanism or do I need to add it in?

Edit: Actually, it looks like that may have been mentioned in one of the comments on the feature request, and the work done by cc 9cii would suggest it needs to be done using some sort of command, though I'll have to look into that a bit more. Anyway, if someone could confirm that there isn't already some code that does this, I would appreciate it.

User avatar
Zini
Posts: 5117
Joined: 06 Aug 2011, 15:16

Re: Render Path Grid v2

Post by Zini » 29 Apr 2016, 07:47

From what I remember the nested column implementation is indeed missing some update signals. This will require fixing.

aesylwinn
Posts: 211
Joined: 14 Dec 2015, 20:30

Re: Render Path Grid v2

Post by aesylwinn » 30 Apr 2016, 06:04

Well unfortunately there is quite a bit of complexity introduced by the NestedColumnAdapter implementation. Since each child class handles rows and columns in a specific way, I am unsure if I should emit the "row" and/or "column" that changed. Doing so has the potential to complicate any modifications to the code. For example:

Code: Select all

void PathgridPointListAdapter::addRow(Record<Pathgrid>& record, int position) const
{
    Pathgrid pathgrid = record.get();

    ESM::Pathgrid::PointList& points = pathgrid.mPoints;

    // blank row
    ESM::Pathgrid::Point point;
    point.mX = 0;
    point.mY = 0;
    point.mZ = 0;
    point.mAutogenerated = 0;
    point.mConnectionNum = 0;
    point.mUnknown = 0;

    // inserting a point should trigger re-indexing of the edges
    //
    // FIXME: does not auto refresh edges table view
    std::vector<ESM::Pathgrid::Edge>::iterator iter = pathgrid.mEdges.begin();
    for (;iter != pathgrid.mEdges.end(); ++iter)
    {
        if ((*iter).mV0 >= position)
            (*iter).mV0++;
        if ((*iter).mV1 >= position)
            (*iter).mV1++;
    }

    points.insert(points.begin()+position, point);
    pathgrid.mData.mS2 += 1; // increment the number of points

    record.setModified (pathgrid);
}
This code meant to insert a point also happens to modify the pathgrid edge list. I can repeat that algorithm in the rendering update code, but it would be more future proof to just reconstruct the affected pathgrid. Also, the NestedColumnAdapter class is meant to be an abstraction for Qt, and having a bit of code that unabstracts it outside of the class seems to be a bad idea to me. Any changes to what a row/column defined would require the outside code to be changed as well.

Of course, all of that assumes that I am adding a generic signal to the NestedColumnAdapter class. Perhaps I should drop that idea and add specific signals to the corresponding pathgrid adapter classes.

In short, should I emit a signal that only alerts if a NestedColumnAdapter implementation modified data, emit a signal that also gives the modified row and column, or skip the generic solution and directly add a signal to the pathgrid specific adapters?

Also, I don't understand why the point isn't just added to the end of the list in the code I referenced. :lol:

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest